1. 27 Nov, 2014 23 commits
  2. 20 Nov, 2014 17 commits
    • Nadav Amit's avatar
      KVM: x86: Fix uninitialized op->type for some immediate values · 7818ad4c
      Nadav Amit authored
      commit d29b9d7e upstream.
      
      The emulator could reuse an op->type from a previous instruction for some
      immediate values.  If it mistakenly considers the operands as memory
      operands, it will performs a memory read and overwrite op->val.
      
      Consider for instance the ROR instruction - src2 (the number of times)
      would be read from memory instead of being used as immediate.
      
      Mark every immediate operand as such to avoid this problem.
      
      Fixes: c44b4c6aSigned-off-by: default avatarNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7818ad4c
    • Joe Thornber's avatar
      dm thin: grab a virtual cell before looking up the mapping · 67d30efb
      Joe Thornber authored
      commit c822ed96 upstream.
      
      Avoids normal IO racing with discard.
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      67d30efb
    • Herbert Xu's avatar
      macvtap: Fix csum_start when VLAN tags are present · 21ddb337
      Herbert Xu authored
      commit 3ce9b20f upstream.
      
      When VLAN is in use in macvtap_put_user, we end up setting
      csum_start to the wrong place.  The result is that the whoever
      ends up doing the checksum setting will corrupt the packet instead
      of writing the checksum to the expected location, usually this
      means writing the checksum with an offset of -4.
      
      This patch fixes this by adjusting csum_start when VLAN tags are
      detected.
      
      Fixes: f09e2249 ("macvtap: restore vlan header on user read")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      
      Cheers,
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      21ddb337
    • Herbert Xu's avatar
      tun: Fix csum_start with VLAN acceleration · e5d98eee
      Herbert Xu authored
      commit a8f9bfdf upstream.
      
      When VLAN acceleration is in use on the xmit path, we end up
      setting csum_start to the wrong place.  The result is that the
      whoever ends up doing the checksum setting will corrupt the packet
      instead of writing the checksum to the expected location, usually
      this means writing the checksum with an offset of -4.
      
      This patch fixes this by adjusting csum_start when VLAN acceleration
      is detected.
      
      Fixes: 6680ec68 ("tuntap: hardware vlan tx support")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e5d98eee
    • Emmanuel Grumbach's avatar
      iwlwifi: fix RFkill while calibrating · bcc79e2d
      Emmanuel Grumbach authored
      commit 31b8b343 upstream.
      
      If the RFkill interrupt fires while we calibrate, it would
      make the firmware fail and the driver wasn't able to recover.
      Change the flow so that the driver will kill the firmware
      in that case.
      
      Since we have now two flows that are calling
      trans_stop_device (the RFkill interrupt and the
      op_mode_mvm_start function) - we need to better sync this.
      Use the STATUS_DEVICE_ENABLED in the pcie transport in an
      atomic way to achieve this.
      
      This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=86231Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Reviewed-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [ luis: used Emmanuel's backport to 3.17 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bcc79e2d
    • Johannes Berg's avatar
      mac80211: fix use-after-free in defragmentation · d792d804
      Johannes Berg authored
      commit b8fff407 upstream.
      
      Upon receiving the last fragment, all but the first fragment
      are freed, but the multicast check for statistics at the end
      of the function refers to the current skb (the last fragment)
      causing a use-after-free bug.
      
      Since multicast frames cannot be fragmented and we check for
      this early in the function, just modify that check to also
      do the accounting to fix the issue.
      Reported-by: default avatarYosef Khyal <yosefx.khyal@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d792d804
    • Andrew Lunn's avatar
      ARM: mvebu: armada xp: Generalize use of i2c quirk · 32a372f2
      Andrew Lunn authored
      commit 5129ee22 upstream.
      
      A second product has come to light which makes use of the A0 stepping
      of the Armada XP SoC. A0 stepping has a hardware bug in the i2c core
      meaning that hardware offload does not work, resulting in the kernel
      failing to boot. The quirk detects that the kernel is running on an A0
      stepping SoC and disables the use of hardware offload.
      
      Currently the quirk is only enabled for PlatHome Openblocks AX3. The
      AX3 has been produced with both A0 and B0 stepping SoCs. The second
      product is the Lenovo Iomega IX4-300d. It seems likely that this
      device will also swap from A0 to B0 SoC sometime during its life.
      
      If there are two products using A0, it seems likely there are more
      products with A0. Also, since the number of A0 SoCs is limited, these
      products are also likely to transition to B0. Hence detecting at run
      time is the safest option. So enable the quirk for all Armada XP
      boards.
      
      Tested on an AX3 with A0 stepping.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Acked-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Acked-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Fixes: 930ab3d4: ("i2c: mv64xxx: Add I2C Transaction Generator support")
      Link: https://lkml.kernel.org/r/1406395238-29758-2-git-send-email-andrew@lunn.chSigned-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      32a372f2
    • Junjie Mao's avatar
      x86, kaslr: Prevent .bss from overlaping initrd · 214f1dd0
      Junjie Mao authored
      commit e6023367 upstream.
      
      When choosing a random address, the current implementation does not take into
      account the reversed space for .bss and .brk sections. Thus the relocated kernel
      may overlap other components in memory. Here is an example of the overlap from a
      x86_64 kernel in qemu (the ranges of physical addresses are presented):
      
       Physical Address
      
          0x0fe00000                  --+--------------------+  <-- randomized base
                                     /  |  relocated kernel  |
                         vmlinux.bin    | (from vmlinux.bin) |
          0x1336d000    (an ELF file)   +--------------------+--
                                     \  |                    |  \
          0x1376d870                  --+--------------------+   |
                                        |    relocs table    |   |
          0x13c1c2a8                    +--------------------+   .bss and .brk
                                        |                    |   |
          0x13ce6000                    +--------------------+   |
                                        |                    |  /
          0x13f77000                    |       initrd       |--
                                        |                    |
          0x13fef374                    +--------------------+
      
      The initrd image will then be overwritten by the memset during early
      initialization:
      
      [    1.655204] Unpacking initramfs...
      [    1.662831] Initramfs unpacking failed: junk in compressed archive
      
      This patch prevents the above situation by requiring a larger space when looking
      for a random kernel base, so that existing logic can effectively avoids the
      overlap.
      
      [kees: switched to perl to avoid hex translation pain in mawk vs gawk]
      [kees: calculated overlap without relocs table]
      
      Fixes: 82fa9637 ("x86, kaslr: Select random position from e820 maps")
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarJunjie Mao <eternal.n08@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Link: http://lkml.kernel.org/r/1414762838-13067-1-git-send-email-eternal.n08@gmail.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      214f1dd0
    • Borislav Petkov's avatar
      x86, microcode, AMD: Fix early ucode loading on 32-bit · 0b8d5bfa
      Borislav Petkov authored
      commit 4750a0d1 upstream.
      
      Konrad triggered the following splat below in a 32-bit guest on an AMD
      box. As it turns out, in save_microcode_in_initrd_amd() we're using the
      *physical* address of the container *after* we have enabled paging and
      thus we #PF in load_microcode_amd() when trying to access the microcode
      container in the ramdisk range.
      
      Because the ramdisk is exactly there:
      
      [    0.000000] RAMDISK: [mem 0x35e04000-0x36ef9fff]
      
      and we fault at 0x35e04304.
      
      And since this guest doesn't relocate the ramdisk, we don't do the
      computation which will give us the correct virtual address and we end up
      with the PA.
      
      So, we should actually be using virtual addresses on 32-bit too by the
      time we're freeing the initrd. Do that then!
      
      Unpacking initramfs...
      BUG: unable to handle kernel paging request at 35d4e304
      IP: [<c042e905>] load_microcode_amd+0x25/0x4a0
      *pde = 00000000
      Oops: 0000 [#1] SMP
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.1-302.fc21.i686 #1
      Hardware name: Xen HVM domU, BIOS 4.4.1 10/01/2014
      task: f5098000 ti: f50d0000 task.ti: f50d0000
      EIP: 0060:[<c042e905>] EFLAGS: 00010246 CPU: 0
      EIP is at load_microcode_amd+0x25/0x4a0
      EAX: 00000000 EBX: f6e9ec4c ECX: 00001ec4 EDX: 00000000
      ESI: f5d4e000 EDI: 35d4e2fc EBP: f50d1ed0 ESP: f50d1e94
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      CR0: 8005003b CR2: 35d4e304 CR3: 00e33000 CR4: 000406d0
      Stack:
       00000000 00000000 f50d1ebc f50d1ec4 f5d4e000 c0d7735a f50d1ed0 15a3d17f
       f50d1ec4 00600f20 00001ec4 bfb83203 f6e9ec4c f5d4e000 c0d7735a f50d1ed8
       c0d80861 f50d1ee0 c0d80429 f50d1ef0 c0d889a9 f5d4e000 c0000000 f50d1f04
      Call Trace:
      ? unpack_to_rootfs
      ? unpack_to_rootfs
      save_microcode_in_initrd_amd
      save_microcode_in_initrd
      free_initrd_mem
      populate_rootfs
      ? unpack_to_rootfs
      do_one_initcall
      ? unpack_to_rootfs
      ? repair_env_string
      ? proc_mkdir
      kernel_init_freeable
      kernel_init
      ret_from_kernel_thread
      ? rest_init
      Reported-and-tested-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      References: https://bugzilla.redhat.com/show_bug.cgi?id=1158204
      Fixes: 75a1ba5b ("x86, microcode, AMD: Unify valid container checks")
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/20141101100100.GA4462@pd.tnicSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0b8d5bfa
    • Jan Kara's avatar
      block: Fix computation of merged request priority · 0e4110b2
      Jan Kara authored
      commit ece9c72a upstream.
      
      Priority of a merged request is computed by ioprio_best(). If one of the
      requests has undefined priority (IOPRIO_CLASS_NONE) and another request
      has priority from IOPRIO_CLASS_BE, the function will return the
      undefined priority which is wrong. Fix the function to properly return
      priority of a request with the defined priority.
      
      Fixes: d58cdfb8Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0e4110b2
    • Richard Guy Briggs's avatar
      audit: AUDIT_FEATURE_CHANGE message format missing delimiting space · 0960c0d8
      Richard Guy Briggs authored
      commit 897f1acb upstream.
      
      Add a space between subj= and feature= fields to make them parsable.
      Signed-off-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0960c0d8
    • Johannes Berg's avatar
      mac80211: properly flush delayed scan work on interface removal · b1101d48
      Johannes Berg authored
      commit 46238845 upstream.
      
      When an interface is deleted, an ongoing hardware scan is canceled and
      the driver must abort the scan, at the very least reporting completion
      while the interface is removed.
      
      However, if it scheduled the work that might only run after everything
      is said and done, which leads to cfg80211 warning that the scan isn't
      reported as finished yet; this is no fault of the driver, it already
      did, but mac80211 hasn't processed it.
      
      To fix this situation, flush the delayed work when the interface being
      removed is the one that was executing the scan.
      Reported-by: default avatarSujith Manoharan <sujith@msujith.org>
      Tested-by: default avatarSujith Manoharan <sujith@msujith.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b1101d48
    • Luciano Coelho's avatar
      mac80211: schedule the actual switch of the station before CSA count 0 · 074c0bf0
      Luciano Coelho authored
      commit ff1e417c upstream.
      
      Due to the time it takes to process the beacon that started the CSA
      process, we may be late for the switch if we try to reach exactly
      beacon 0.  To avoid that, use count - 1 when calculating the switch time.
      Reported-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      074c0bf0
    • Luciano Coelho's avatar
      mac80211: use secondary channel offset IE also beacons during CSA · da82b513
      Luciano Coelho authored
      commit 84469a45 upstream.
      
      If we are switching from an HT40+ to an HT40- channel (or vice-versa),
      we need the secondary channel offset IE to specify what is the
      post-CSA offset to be used.  This applies both to beacons and to probe
      responses.
      
      In ieee80211_parse_ch_switch_ie() we were ignoring this IE from
      beacons and using the *current* HT information IE instead.  This was
      causing us to use the same offset as before the switch.
      
      Fix that by using the secondary channel offset IE also for beacons and
      don't ever use the pre-switch offset.  Additionally, remove the
      "beacon" argument from ieee80211_parse_ch_switch_ie(), since it's not
      needed anymore.
      Reported-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      da82b513
    • Krzysztof Kozlowski's avatar
      power: charger-manager: Fix accessing invalidated power supply after charger unbind · 8ff3aebf
      Krzysztof Kozlowski authored
      commit cdaf3e15 upstream.
      
      The charger manager obtained in probe references to power supplies for
      all chargers with power_supply_get_by_name() for later usage. However
      if such charger driver was removed then this reference would point to
      old power supply (from driver which was removed).
      
      This lead to accessing invalid memory which could be observed with:
      $ echo "max77693-charger" > /sys/bus/platform/drivers/max77693-charger/unbind
      $ grep . /sys/devices/virtual/power_supply/battery/charger.0/*
      $ grep . /sys/devices/virtual/power_supply/battery/*
      [   15.339817] Unable to handle kernel paging request at virtual address 0001c12c
      [   15.346187] pgd = edd08000
      [   15.348814] [0001c12c] *pgd=6dce2831, *pte=00000000, *ppte=00000000
      [   15.355075] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
      [   15.360967] Modules linked in:
      [   15.364010] CPU: 2 PID: 1388 Comm: grep Not tainted 3.17.0-next-20141007-00027-ga95e761db1b0 #245
      [   15.372859] task: ee03ad00 ti: edcf6000 task.ti: edcf6000
      [   15.378241] PC is at 0x1c12c
      [   15.381113] LR is at is_ext_pwr_online+0x30/0x6c
      [   15.385706] pc : [<0001c12c>]    lr : [<c0339fc4>]    psr: a0000013
      [   15.385706] sp : edcf7e88  ip : 00000000  fp : 00000000
      [   15.397161] r10: eeb02c08  r9 : c04b1f84  r8 : eeb02c00
      [   15.402369] r7 : edc69a10  r6 : eea6ac10  r5 : eea6ac10  r4 : 00000004
      [   15.408878] r3 : 0001c12c  r2 : edcf7e8c  r1 : 00000004  r0 : ee914418
      [   15.415390] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      [   15.422506] Control: 10c5387d  Table: 6dd0804a  DAC: 00000015
      [   15.428236] Process grep (pid: 1388, stack limit = 0xedcf6240)
      [   15.434050] Stack: (0xedcf7e88 to 0xedcf8000)
      [   15.438395] 7e80:                   ee03ad00 00000000 edcf7f80 eea6aca8 edcf7ec4 c033b7b0
      [   15.446554] 7ea0: 00000001 ee1cc3f0 00000004 c06e1e44 eebdc000 c06e1e44 eeb02c00 c0337144
      [   15.454713] 7ec0: ee2dac68 c005cffc ee1cc3c0 c06e1e44 00000fff 00001000 eebdc000 c0278ca8
      [   15.462872] 7ee0: c0278c8c ee1cc3c0 eeb7ce00 c014422c edcf7f20 00008000 ee1cc3c0 ee9a48c0
      [   15.471030] 7f00: 00000001 00000001 edcf7f80 c0142d94 c0142d70 c01060f4 00021000 ee1cc3f0
      [   15.479190] 7f20: 00000000 00000000 c06a2150 eebdc000 2e7ec000 ee9a48c0 00008000 00021000
      [   15.487349] 7f40: edcf7f80 00008000 edcf6000 00021000 00021000 c00e39a4 00000000 ee9a48c0
      [   15.495508] 7f60: 00004000 00000000 00000000 ee9a48c0 ee9a48c0 00008000 00021000 c00e3aa0
      [   15.503668] 7f80: 00000000 00000000 0001f2e0 0001f2e0 00021000 00001000 00000003 c000f364
      [   15.511826] 7fa0: 00000000 c000f1a0 0001f2e0 00021000 00000003 00021000 00008000 00000000
      [   15.519986] 7fc0: 0001f2e0 00021000 00001000 00000003 00000001 000205e8 00000000 00021000
      [   15.528145] 7fe0: 00008000 bebbe910 0000a7ad b6edc49c 60000010 00000003 aaaaaaaa aaaaaaaa
      [   15.536320] [<c0339fc4>] (is_ext_pwr_online) from [<c033b7b0>] (charger_get_property+0x170/0x314)
      [   15.545164] [<c033b7b0>] (charger_get_property) from [<c0337144>] (power_supply_show_property+0x48/0x20c)
      [   15.554719] [<c0337144>] (power_supply_show_property) from [<c0278ca8>] (dev_attr_show+0x1c/0x48)
      [   15.563577] [<c0278ca8>] (dev_attr_show) from [<c014422c>] (sysfs_kf_seq_show+0x84/0x104)
      [   15.571725] [<c014422c>] (sysfs_kf_seq_show) from [<c0142d94>] (kernfs_seq_show+0x24/0x28)
      [   15.579973] [<c0142d94>] (kernfs_seq_show) from [<c01060f4>] (seq_read+0x1b0/0x484)
      [   15.587614] [<c01060f4>] (seq_read) from [<c00e39a4>] (vfs_read+0x88/0x144)
      [   15.594552] [<c00e39a4>] (vfs_read) from [<c00e3aa0>] (SyS_read+0x40/0x8c)
      [   15.601417] [<c00e3aa0>] (SyS_read) from [<c000f1a0>] (ret_fast_syscall+0x0/0x48)
      [   15.608877] Code: bad PC value
      [   15.611991] ---[ end trace a88fcc95208db283 ]---
      
      The charger-manager should get reference to charger power supply on
      each use of get_property callback.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 3bb3dbbd ("power_supply: Add initial Charger-Manager driver")
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8ff3aebf
    • Krzysztof Kozlowski's avatar
      power: charger-manager: Fix accessing invalidated power supply after fuel gauge unbind · d4ce860a
      Krzysztof Kozlowski authored
      commit bdbe8144 upstream.
      
      The charger manager obtained reference to fuel gauge power supply in probe
      with power_supply_get_by_name() for later usage. However if fuel gauge
      driver was removed and re-added then this reference would point to old
      power supply (from driver which was removed).
      
      This lead to accessing old (and probably invalid) memory which could be
      observed with:
      $ echo "12-0036" > /sys/bus/i2c/drivers/max17042/unbind
      $ echo "12-0036" > /sys/bus/i2c/drivers/max17042/bind
      $ cat /sys/devices/virtual/power_supply/battery/capacity
      [  240.480084] INFO: task cat:1393 blocked for more than 120 seconds.
      [  240.484799]       Not tainted 3.17.0-next-20141007-00028-ge60b6dd79570 #203
      [  240.491782] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  240.499589] cat             D c0469530     0  1393      1 0x00000000
      [  240.505947] [<c0469530>] (__schedule) from [<c0469d3c>] (schedule_preempt_disabled+0x14/0x20)
      [  240.514449] [<c0469d3c>] (schedule_preempt_disabled) from [<c046af08>] (mutex_lock_nested+0x1bc/0x458)
      [  240.523736] [<c046af08>] (mutex_lock_nested) from [<c0287a98>] (regmap_read+0x30/0x60)
      [  240.531647] [<c0287a98>] (regmap_read) from [<c032238c>] (max17042_get_property+0x2e8/0x350)
      [  240.540055] [<c032238c>] (max17042_get_property) from [<c03247d8>] (charger_get_property+0x264/0x348)
      [  240.549252] [<c03247d8>] (charger_get_property) from [<c0320764>] (power_supply_show_property+0x48/0x1e0)
      [  240.558808] [<c0320764>] (power_supply_show_property) from [<c027308c>] (dev_attr_show+0x1c/0x48)
      [  240.567664] [<c027308c>] (dev_attr_show) from [<c0141fb0>] (sysfs_kf_seq_show+0x84/0x104)
      [  240.575814] [<c0141fb0>] (sysfs_kf_seq_show) from [<c0140b18>] (kernfs_seq_show+0x24/0x28)
      [  240.584061] [<c0140b18>] (kernfs_seq_show) from [<c0104574>] (seq_read+0x1b0/0x484)
      [  240.591702] [<c0104574>] (seq_read) from [<c00e1e24>] (vfs_read+0x88/0x144)
      [  240.598640] [<c00e1e24>] (vfs_read) from [<c00e1f20>] (SyS_read+0x40/0x8c)
      [  240.605507] [<c00e1f20>] (SyS_read) from [<c000e760>] (ret_fast_syscall+0x0/0x48)
      [  240.612952] 4 locks held by cat/1393:
      [  240.616589]  #0:  (&p->lock){+.+.+.}, at: [<c01043f4>] seq_read+0x30/0x484
      [  240.623414]  #1:  (&of->mutex){+.+.+.}, at: [<c01417dc>] kernfs_seq_start+0x1c/0x8c
      [  240.631086]  #2:  (s_active#31){++++.+}, at: [<c01417e4>] kernfs_seq_start+0x24/0x8c
      [  240.638777]  #3:  (&map->mutex){+.+...}, at: [<c0287a98>] regmap_read+0x30/0x60
      
      The charger-manager should get reference to fuel gauge power supply on
      each use of get_property callback. The thermal zone 'tzd' field of
      power supply should not be used because of the same reason.
      
      Additionally this change solves also the issue with nested
      thermal_zone_get_temp() calls and related false lockdep positive for
      deadlock for thermal zone's mutex [1]. When fuel gauge is used as source of
      temperature then the charger manager forwards its get_temp calls to fuel
      gauge thermal zone. So actually different mutexes are used (one for
      charger manager thermal zone and second for fuel gauge thermal zone) but
      for lockdep this is one class of mutex.
      
      The recursion is removed by retrieving temperature through power
      supply's get_property().
      
      In case external thermal zone is used ('cm-thermal-zone' property is
      present in DTS) the recursion does not exist. Charger manager simply
      exports POWER_SUPPLY_PROP_TEMP_AMBIENT property (instead of
      POWER_SUPPLY_PROP_TEMP) thus no thermal zone is created for this power
      supply.
      
      [1] https://lkml.org/lkml/2014/10/6/309Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 3bb3dbbd ("power_supply: Add initial Charger-Manager driver")
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d4ce860a
    • Krzysztof Kozlowski's avatar
      power: bq2415x_charger: Fix memory leak on DTS parsing error · 9863a157
      Krzysztof Kozlowski authored
      commit 21e863b2 upstream.
      
      Memory allocated for 'name' was leaking if required binding properties
      were not present.
      
      The memory for 'name' was allocated early at probe with kasprintf(). It
      was freed in error paths executed before and after parsing DTS but not
      in that error path.
      
      Fix the error path for parsing device tree properties.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: faffd234 ("bq2415x_charger: Add DT support")
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9863a157