1. 14 12月, 2014 3 次提交
    • J
      mm/page_owner: keep track of page owners · 48c96a36
      Joonsoo Kim 提交于
      This is the page owner tracking code which is introduced so far ago.  It
      is resident on Andrew's tree, though, nobody tried to upstream so it
      remain as is.  Our company uses this feature actively to debug memory leak
      or to find a memory hogger so I decide to upstream this feature.
      
      This functionality help us to know who allocates the page.  When
      allocating a page, we store some information about allocation in extra
      memory.  Later, if we need to know status of all pages, we can get and
      analyze it from this stored information.
      
      In previous version of this feature, extra memory is statically defined in
      struct page, but, in this version, extra memory is allocated outside of
      struct page.  It enables us to turn on/off this feature at boottime
      without considerable memory waste.
      
      Although we already have tracepoint for tracing page allocation/free,
      using it to analyze page owner is rather complex.  We need to enlarge the
      trace buffer for preventing overlapping until userspace program launched.
      And, launched program continually dump out the trace buffer for later
      analysis and it would change system behaviour with more possibility rather
      than just keeping it in memory, so bad for debug.
      
      Moreover, we can use page_owner feature further for various purposes.  For
      example, we can use it for fragmentation statistics implemented in this
      patch.  And, I also plan to implement some CMA failure debugging feature
      using this interface.
      
      I'd like to give the credit for all developers contributed this feature,
      but, it's not easy because I don't know exact history.  Sorry about that.
      Below is people who has "Signed-off-by" in the patches in Andrew's tree.
      
      Contributor:
      Alexander Nyberg <alexn@dsv.su.se>
      Mel Gorman <mgorman@suse.de>
      Dave Hansen <dave@linux.vnet.ibm.com>
      Minchan Kim <minchan@kernel.org>
      Michal Nazarewicz <mina86@mina86.com>
      Andrew Morton <akpm@linux-foundation.org>
      Jungsoo Son <jungsoo.son@lge.com>
      Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: Jungsoo Son <jungsoo.son@lge.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      48c96a36
    • J
      mm/debug-pagealloc: make debug-pagealloc boottime configurable · 031bc574
      Joonsoo Kim 提交于
      Now, we have prepared to avoid using debug-pagealloc in boottime.  So
      introduce new kernel-parameter to disable debug-pagealloc in boottime, and
      makes related functions to be disabled in this case.
      
      Only non-intuitive part is change of guard page functions.  Because guard
      page is effective only if debug-pagealloc is enabled, turning off
      according to debug-pagealloc is reasonable thing to do.
      Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: Jungsoo Son <jungsoo.son@lge.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      031bc574
    • L
      hugetlb: fix hugepages= entry in kernel-parameters.txt · 27ec26ec
      Luiz Capitulino 提交于
      The hugepages= entry in kernel-parameters.txt states that 1GB pages can
      only be allocated at boot time and not freed afterwards.  This is not
      true since commit 944d9fec ("hugetlb: add support for gigantic page
      allocation at runtime"), at least for x86_64.
      
      Instead of adding arch-specifc observations to the hugepages= entry,
      this commit just drops the out of date information.  Further information
      about arch-specific support and available features can be obtained in
      the hugetlb documentation.
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Acked-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      27ec26ec
  2. 11 12月, 2014 1 次提交
    • P
      kernel: add panic_on_warn · 9e3961a0
      Prarit Bhargava 提交于
      There have been several times where I have had to rebuild a kernel to
      cause a panic when hitting a WARN() in the code in order to get a crash
      dump from a system.  Sometimes this is easy to do, other times (such as
      in the case of a remote admin) it is not trivial to send new images to
      the user.
      
      A much easier method would be a switch to change the WARN() over to a
      panic.  This makes debugging easier in that I can now test the actual
      image the WARN() was seen on and I do not have to engage in remote
      debugging.
      
      This patch adds a panic_on_warn kernel parameter and
      /proc/sys/kernel/panic_on_warn calls panic() in the
      warn_slowpath_common() path.  The function will still print out the
      location of the warning.
      
      An example of the panic_on_warn output:
      
      The first line below is from the WARN_ON() to output the WARN_ON()'s
      location.  After that the panic() output is displayed.
      
          WARNING: CPU: 30 PID: 11698 at /home/prarit/dummy_module/dummy-module.c:25 init_dummy+0x1f/0x30 [dummy_module]()
          Kernel panic - not syncing: panic_on_warn set ...
      
          CPU: 30 PID: 11698 Comm: insmod Tainted: G        W  OE  3.17.0+ #57
          Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
           0000000000000000 000000008e3f87df ffff88080f093c38 ffffffff81665190
           0000000000000000 ffffffff818aea3d ffff88080f093cb8 ffffffff8165e2ec
           ffffffff00000008 ffff88080f093cc8 ffff88080f093c68 000000008e3f87df
          Call Trace:
           [<ffffffff81665190>] dump_stack+0x46/0x58
           [<ffffffff8165e2ec>] panic+0xd0/0x204
           [<ffffffffa038e05f>] ? init_dummy+0x1f/0x30 [dummy_module]
           [<ffffffff81076b90>] warn_slowpath_common+0xd0/0xd0
           [<ffffffffa038e040>] ? dummy_greetings+0x40/0x40 [dummy_module]
           [<ffffffff81076c8a>] warn_slowpath_null+0x1a/0x20
           [<ffffffffa038e05f>] init_dummy+0x1f/0x30 [dummy_module]
           [<ffffffff81002144>] do_one_initcall+0xd4/0x210
           [<ffffffff811b52c2>] ? __vunmap+0xc2/0x110
           [<ffffffff810f8889>] load_module+0x16a9/0x1b30
           [<ffffffff810f3d30>] ? store_uevent+0x70/0x70
           [<ffffffff810f49b9>] ? copy_module_from_fd.isra.44+0x129/0x180
           [<ffffffff810f8ec6>] SyS_finit_module+0xa6/0xd0
           [<ffffffff8166cf29>] system_call_fastpath+0x12/0x17
      
      Successfully tested by me.
      
      hpa said: There is another very valid use for this: many operators would
      rather a machine shuts down than being potentially compromised either
      functionally or security-wise.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Fabian Frederick <fabf@skynet.be>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9e3961a0
  3. 04 12月, 2014 1 次提交
  4. 14 11月, 2014 1 次提交
  5. 12 11月, 2014 1 次提交
    • D
      intel_pstate: Add support for HWP · 2f86dc4c
      Dirk Brandewie 提交于
      Add support of Hardware Managed Performance States (HWP) described in Volume 3
      section 14.4 of the SDM.
      
      With HWP enbaled intel_pstate will no longer be responsible for selecting P
      states for the processor. intel_pstate will continue to register to
      the cpufreq core as the scaling driver for CPUs implementing
      HWP. In HWP mode intel_pstate provides three functions reporting
      frequency to the cpufreq core, support for the set_policy() interface
      from the core and maintaining the intel_pstate sysfs interface in
      /sys/devices/system/cpu/intel_pstate.  User preferences expressed via
      the set_policy() interface or the sysfs interface are forwared to the
      CPU via the HWP MSR interface.
      Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2f86dc4c
  6. 08 11月, 2014 1 次提交
  7. 01 11月, 2014 1 次提交
  8. 30 10月, 2014 1 次提交
  9. 27 10月, 2014 1 次提交
  10. 25 10月, 2014 1 次提交
  11. 13 10月, 2014 1 次提交
    • N
      powerpc/numa: Add ability to disable and debug topology updates · 2d73bae1
      Nishanth Aravamudan 提交于
      We have hit a few customer issues with the topology update code (VPHN
      and PRRN). It would be nice to be able to debug the notifications coming
      from the hypervisor in both cases to the LPAR, as well as to disable
      responding to the notifications at boot-time, to narrow down the source
      of the problems. Add a basic level of such functionality, similar to the
      numa= command-line parameter. We already have a toggle in
      /proc/powerpc/topology_updates that allows run-time enabling/disabling,
      so the updates can be started at run-time if desired. But the bugs we've
      run into have occured during boot or very shortly after coming to login,
      and have resulted in a broken NUMA topology.
      Signed-off-by: NNishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      2d73bae1
  12. 12 10月, 2014 1 次提交
    • D
      Input: i8042 - disable active multiplexing by default · 68da1664
      Dmitry Torokhov 提交于
      Active multiplexing is a nice feature as it allows several pointing devices
      (such as touchpad and external mouse) use their native protocols at the
      same time. Unfortunately many manufacturers do not implement the feature
      properly even though they advertise it. The problematic implementations are
      never fixed, since Windows by default does not use this mode, and move from
      one BIOS/model of laptop to another. When active multiplexing is broken
      turning it on usually results in touchpad, keyboard, or both unresponsive.
      
      With PS/2 usage on decline (most of PS/2 devices in use nowadays are
      internal laptop touchpads), I expect number of users who have laptops with
      working MUX implementation, docking stations with external PS/2 ports, and
      who are still using external PS/2 mice, to be rather small. Let's flip the
      default to be OFF and allow activating it through i8042.nomux=0 kernel
      option.  We'll also keep DMI table where we can record known good models.
      Acked-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      68da1664
  13. 10 10月, 2014 2 次提交
  14. 04 10月, 2014 3 次提交
    • D
      efi: Add kernel param efi=noruntime · 5ae3683c
      Dave Young 提交于
      noefi kernel param means actually disabling efi runtime, Per suggestion
      from Leif Lindholm efi=noruntime should be better. But since noefi is
      already used in X86 thus just adding another param efi=noruntime for
      same purpose.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      5ae3683c
    • D
      efi: Move noefi early param code out of x86 arch code · b2e0a54a
      Dave Young 提交于
      noefi param can be used for arches other than X86 later, thus move it
      out of x86 platform code.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      b2e0a54a
    • M
      efi: Add efi= parameter parsing to the EFI boot stub · 5a17dae4
      Matt Fleming 提交于
      We need a way to customize the behaviour of the EFI boot stub, in
      particular, we need a way to disable the "chunking" workaround, used
      when reading files from the EFI System Partition.
      
      One of my machines doesn't cope well when reading files in 1MB chunks to
      a buffer above the 4GB mark - it appears that the "chunking" bug
      workaround triggers another firmware bug. This was only discovered with
      commit 4bf7111f ("x86/efi: Support initrd loaded above 4G"), and
      that commit is perfectly valid. The symptom I observed was a corrupt
      initrd rather than any kind of crash.
      
      efi= is now used to specify EFI parameters in two very different
      execution environments, the EFI boot stub and during kernel boot.
      
      There is also a slight performance optimization by enabling efi=nochunk,
      but that's offset by the fact that you're more likely to run into
      firmware issues, at least on x86. This is the rationale behind leaving
      the workaround enabled by default.
      
      Also provide some documentation for EFI_READ_CHUNK_SIZE and why we're
      using the current value of 1MB.
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Roy Franz <roy.franz@linaro.org>
      Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Borislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      5a17dae4
  15. 01 10月, 2014 1 次提交
  16. 29 9月, 2014 2 次提交
  17. 24 9月, 2014 2 次提交
  18. 18 9月, 2014 1 次提交
    • D
      ima: provide 'ima_appraise=log' kernel option · 2faa6ef3
      Dmitry Kasatkin 提交于
      The kernel boot parameter "ima_appraise" currently defines 'off',
      'enforce' and 'fix' modes.  When designing a policy and labeling
      the system, access to files are either blocked in the default
      'enforce' mode or automatically fixed in the 'fix' mode.  It is
      beneficial to be able to run the system in a logging only mode,
      without fixing it, in order to properly analyze the system. This
      patch adds a 'log' mode to run the system in a permissive mode and
      log the appraisal results.
      Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      2faa6ef3
  19. 17 9月, 2014 2 次提交
  20. 09 9月, 2014 2 次提交
  21. 08 9月, 2014 2 次提交
    • P
      rcu: Add stall-warning checks for RCU-tasks · 52db30ab
      Paul E. McKenney 提交于
      This commit adds a ten-minute RCU-tasks stall warning.  The actual
      time is controlled by the boot/sysfs parameter rcu_task_stall_timeout,
      with values less than or equal to zero disabling the stall warnings.
      The default value is ten minutes, which means that the tasks that have
      not yet responded will get their stacks dumped every ten minutes, until
      they pass through a voluntary context switch.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      52db30ab
    • P
      rcutorture: Add callback-flood test · 38706bc5
      Paul E. McKenney 提交于
      Although RCU is designed to handle arbitrary floods of callbacks, this
      capability is not routinely tested.   This commit therefore adds a
      cbflood capability in which kthreads repeatedly registers large numbers
      of callbacks.  One such kthread is created for each four CPUs (rounding
      up), and the test may be controlled by several cbflood_* kernel boot
      parameters, which control the number of bursts per flood, the number
      of callbacks per burst, the time between bursts, and the time between
      floods.  The default values are large enough to exercise RCU's emergency
      responses to callback flooding.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: David Miller <davem@davemloft.net>
      Reviewed-by: NPranith Kumar <bobby.prani@gmail.com>
      38706bc5
  22. 07 8月, 2014 1 次提交
    • L
      printk: allow increasing the ring buffer depending on the number of CPUs · 23b2899f
      Luis R. Rodriguez 提交于
      The default size of the ring buffer is too small for machines with a
      large amount of CPUs under heavy load.  What ends up happening when
      debugging is the ring buffer overlaps and chews up old messages making
      debugging impossible unless the size is passed as a kernel parameter.
      An idle system upon boot up will on average spew out only about one or
      two extra lines but where this really matters is on heavy load and that
      will vary widely depending on the system and environment.
      
      There are mechanisms to help increase the kernel ring buffer for tracing
      through debugfs, and those interfaces even allow growing the kernel ring
      buffer per CPU.  We also have a static value which can be passed upon
      boot.  Relying on debugfs however is not ideal for production, and
      relying on the value passed upon bootup is can only used *after* an
      issue has creeped up.  Instead of being reactive this adds a proactive
      measure which lets you scale the amount of contributions you'd expect to
      the kernel ring buffer under load by each CPU in the worst case
      scenario.
      
      We use num_possible_cpus() to avoid complexities which could be
      introduced by dynamically changing the ring buffer size at run time,
      num_possible_cpus() lets us use the upper limit on possible number of
      CPUs therefore avoiding having to deal with hotplugging CPUs on and off.
      This introduces the kernel configuration option LOG_CPU_MAX_BUF_SHIFT
      which is used to specify the maximum amount of contributions to the
      kernel ring buffer in the worst case before the kernel ring buffer flips
      over, the size is specified as a power of 2.  The total amount of
      contributions made by each CPU must be greater than half of the default
      kernel ring buffer size (1 << LOG_BUF_SHIFT bytes) in order to trigger
      an increase upon bootup.  The kernel ring buffer is increased to the
      next power of two that would fit the required minimum kernel ring buffer
      size plus the additional CPU contribution.  For example if LOG_BUF_SHIFT
      is 18 (256 KB) you'd require at least 128 KB contributions by other CPUs
      in order to trigger an increase of the kernel ring buffer.  With a
      LOG_CPU_BUF_SHIFT of 12 (4 KB) you'd require at least anything over > 64
      possible CPUs to trigger an increase.  If you had 128 possible CPUs the
      amount of minimum required kernel ring buffer bumps to:
      
         ((1 << 18) + ((128 - 1) * (1 << 12))) / 1024 = 764 KB
      
      Since we require the ring buffer to be a power of two the new required
      size would be 1024 KB.
      
      This CPU contributions are ignored when the "log_buf_len" kernel
      parameter is used as it forces the exact size of the ring buffer to an
      expected power of two value.
      
      [pmladek@suse.cz: fix build]
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Tested-by: NDavidlohr Bueso <davidlohr@hp.com>
      Tested-by: NPetr Mladek <pmladek@suse.cz>
      Reviewed-by: NDavidlohr Bueso <davidlohr@hp.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Arun KS <arunks.linux@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      23b2899f
  23. 02 8月, 2014 1 次提交
  24. 22 7月, 2014 1 次提交
  25. 17 7月, 2014 4 次提交
    • D
      KEYS: validate certificate trust only with builtin keys · 32c4741c
      Dmitry Kasatkin 提交于
      Instead of allowing public keys, with certificates signed by any
      key on the system trusted keyring, to be added to a trusted keyring,
      this patch further restricts the certificates to those signed only by
      builtin keys on the system keyring.
      
      This patch defines a new option 'builtin' for the kernel parameter
      'keys_ownerid' to allow trust validation using builtin keys.
      
      Simplified Mimi's "KEYS: define an owner trusted keyring" patch
      
      Changelog v7:
      - rename builtin_keys to use_builtin_keys
      Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      32c4741c
    • D
      KEYS: validate certificate trust only with selected key · ffb70f61
      Dmitry Kasatkin 提交于
      Instead of allowing public keys, with certificates signed by any
      key on the system trusted keyring, to be added to a trusted keyring,
      this patch further restricts the certificates to those signed by a
      particular key on the system keyring.
      
      This patch defines a new kernel parameter 'ca_keys' to identify the
      specific key which must be used for trust validation of certificates.
      
      Simplified Mimi's "KEYS: define an owner trusted keyring" patch.
      
      Changelog:
      - support for builtin x509 public keys only
      - export "asymmetric_keyid_match"
      - remove ifndefs MODULE
      - rename kernel boot parameter from keys_ownerid to ca_keys
      Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      ffb70f61
    • D
      ima: introduce multi-page collect buffers · 6edf7a89
      Dmitry Kasatkin 提交于
      Use of multiple-page collect buffers reduces:
      1) the number of block IO requests
      2) the number of asynchronous hash update requests
      
      Second is important for HW accelerated hashing, because significant
      amount of time is spent for preparation of hash update operation,
      which includes configuring acceleration HW, DMA engine, etc...
      Thus, HW accelerators are more efficient when working on large
      chunks of data.
      
      This patch introduces usage of multi-page collect buffers. Buffer size
      can be specified using 'ahash_bufsize' module parameter. Default buffer
      size is 4096 bytes.
      
      Changes in v3:
      - kernel parameter replaced with module parameter
      Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      6edf7a89
    • D
      ima: use ahash API for file hash calculation · 3bcced39
      Dmitry Kasatkin 提交于
      Async hash API allows the use of HW acceleration for hash calculation.
      It may give significant performance gain and/or reduce power consumption,
      which might be very beneficial for battery powered devices.
      
      This patch introduces hash calculation using ahash API. ahash performance
      depends on the data size and the particular HW. Depending on the specific
      system, shash performance may be better.
      
      This patch defines 'ahash_minsize' module parameter, which is used to
      define the minimal file size to use with ahash.  If this minimum file size
      is not set or the file is smaller than defined by the parameter, shash will
      be used.
      
      Changes in v3:
      - kernel parameter replaced with module parameter
      - pr_crit replaced with pr_crit_ratelimited
      - more comment changes - Mimi
      
      Changes in v2:
      - ima_ahash_size became as ima_ahash
      - ahash pre-allocation moved out from __init code to be able to use
        ahash crypto modules. Ahash allocated once on the first use.
      - hash calculation falls back to shash if ahash allocation/calculation fails
      - complex initialization separated from variable declaration
      - improved comments
      Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      3bcced39
  26. 15 7月, 2014 2 次提交