Skip to content
GitLab
  1. Oct 26, 2022
    • Jason A. Donenfeld's avatar
      misc: sgi-gru: use explicitly signed char · 67704738
      Jason A. Donenfeld authored 
      

With char becoming unsigned by default, and with `char` alone being
ambiguous and based on architecture, signed chars need to be marked
explicitly as such. This fixes warnings like:

drivers/misc/sgi-gru/grumain.c:711 gru_check_chiplet_assignment() warn: 'gts->ts_user_chiplet_id' is unsigned

Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20221025025223.573543-1-Jason@zx2c4.com


Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67704738
    • Greg Kroah-Hartman's avatar
      Merge tag 'counter-fixes-for-6.1a' of... · 1deac35b
      Greg Kroah-Hartman authored 
      Merge tag 'counter-fixes-for-6.1a' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-linus

William writes:
  "First set of Counter fixes for 6.1 cycle

   Typical driver fixes for races and bugs. This also includes a sparse
   warning fix for the recently introduced counter_array API: the macro
   DEFINE_COUNTER_ARRAY_POLARITY() is reduced to a simple structure
   definition rather than multiple data structure definitions.
   - 104-quad-8
     * Fix race getting function mode and direction
   - microchip-tcb-capture
     * Handle Signal1 read and Synapse
   - ti-ecap-capture
     * fix IS_ERR() vs NULL check
   - counter
     * Reduce DEFINE_COUNTER_ARRAY_POLARITY() to defining counter_array"

* tag 'counter-fixes-for-6.1a' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter:
  counter: 104-quad-8: Fix race getting function mode and direction
  counter: microchip-tcb-capture: Handle Signal1 read and Synapse
  counter: ti-ecap-capture: fix IS_ERR() vs NULL check
  counter: Reduce DEFINE_COUNTER_ARRAY_POLARITY() to defining counter_array
      1deac35b
    • James Clark's avatar
      coresight: cti: Fix hang in cti_disable_hw() · 6746eae4
      James Clark authored 
      cti_enable_hw() and cti_disable_hw() are called from an atomic context
so shouldn't use runtime PM because it can result in a sleep when
communicating with firmware.

Since commit 3c665633 ("Revert "firmware: arm_scmi: Add clock
management to the SCMI power domain""), this causes a hang on Juno when
running the Perf Coresight tests or running this command:

  perf record -e cs_etm//u -- ls

This was also missed until the revert commit because pm_runtime_put()
was called with the wrong device until commit 692c9a49 ("coresight:
cti: Correct the parameter for pm_runtime_put")

With lock and scheduler debugging enabled the following is output:

   coresight cti_sys0: cti_enable_hw -- dev:cti_sys0  parent: 20020000.cti
   BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151
   in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec
   preempt_count: 2, expected: 0
   RCU nest depth: 0, expected: 0
   INFO: lockdep is turned off.
   irq event stamp: 0
   hardirqs last  enabled at (0): [<0000000000000000>] 0x0
   hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948
   softirqs last  enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948
   softirqs last disabled at (0): [<0000000000000000>] 0x0
   CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7
   Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022
   Call trace:
    dump_backtrace+0x134/0x140
    show_stack+0x20/0x58
    dump_stack_lvl+0x8c/0xb8
    dump_stack+0x18/0x34
    __might_resched+0x180/0x228
    __might_sleep+0x50/0x88
    __pm_runtime_resume+0xac/0xb0
    cti_enable+0x44/0x120
    coresight_control_assoc_ectdev+0xc0/0x150
    coresight_enable_path+0xb4/0x288
    etm_event_start+0x138/0x170
    etm_event_add+0x48/0x70
    event_sched_in.isra.122+0xb4/0x280
    merge_sched_in+0x1fc/0x3d0
    visit_groups_merge.constprop.137+0x16c/0x4b0
    ctx_sched_in+0x114/0x1f0
    perf_event_sched_in+0x60/0x90
    ctx_resched+0x68/0xb0
    perf_event_exec+0x138/0x508
    begin_new_exec+0x52c/0xd40
    load_elf_binary+0x6b8/0x17d0
    bprm_execve+0x360/0x7f8
    do_execveat_common.isra.47+0x218/0x238
    __arm64_sys_execve+0x48/0x60
    invoke_syscall+0x4c/0x110
    el0_svc_common.constprop.4+0xfc/0x120
    do_el0_svc+0x34/0xc0
    el0_svc+0x40/0x98
    el0t_64_sync_handler+0x98/0xc0
    el0t_64_sync+0x170/0x174

Fix the issue by removing the runtime PM calls completely. They are not
needed here because it must have already been done when building the
path for a trace.

Fixes: 835d722b

 ("coresight: cti: Initial CoreSight CTI Driver")
Cc: stable <stable@kernel.org>
Reported-by: default avatarAishwarya TCV <Aishwarya.TCV@arm.com>
Reported-by: default avatarCristian Marussi <Cristian.Marussi@arm.com>
Suggested-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: default avatarJames Clark <james.clark@arm.com>
Reviewed-by: default avatarMike Leach <mike.leach@linaro.org>
Tested-by: default avatarMike Leach <mike.leach@linaro.org>
[ Fix build warnings ]
Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20221025131032.1149459-1-suzuki.poulose@arm.com


Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6746eae4
  3. Oct 24, 2022
    • Greg Kroah-Hartman's avatar
      Revert "coresight: cti: Fix hang in cti_disable_hw()" · d76308f0
      Greg Kroah-Hartman authored 
      This reverts commit 665c157e

.

It causes reported build warnings:

drivers/hwtracing/coresight/coresight-cti-core.c: In functio
n 'cti_enable_hw':
drivers/hwtracing/coresight/coresight-cti-core.c:93:24: warning: unused variable 'dev' [-Wunused-variable]
   93 |         struct device *dev = &drvdata->csdev->dev;
      |                        ^~~
drivers/hwtracing/coresight/coresight-cti-core.c: In function 'cti_disable_hw':
drivers/hwtracing/coresight/coresight-cti-core.c:154:24: warning: unused variable 'dev' [-Wunused-variable]
  154 |         struct device *dev = &drvdata->csdev->dev;
      |                        ^~~

Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
Cc: Aishwarya TCV <Aishwarya.TCV@arm.com>
Cc: Cristian Marussi <Cristian.Marussi@arm.com>
Cc: Suzuki Poulose <Suzuki.Poulose@arm.com>
Cc: James Clark <james.clark@arm.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Fixes: 665c157e ("coresight: cti: Fix hang in cti_disable_hw()")
Link: https://lore.kernel.org/r/20221024135752.2b83af97@canb.auug.org.au


Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d76308f0
    • William Breathitt Gray's avatar
      counter: 104-quad-8: Fix race getting function mode and direction · d501d378
      William Breathitt Gray authored 
      The quad8_action_read() function checks the Count function mode and
Count direction without first acquiring a lock. This is a race condition
because the function mode could change by the time the direction is
checked.

Because the quad8_function_read() already acquires a lock internally,
the quad8_function_read() is refactored to spin out the no-lock code to
a new quad8_function_get() function.

To resolve the race condition in quad8_action_read(), a lock is acquired
before calling quad8_function_get() and quad8_direction_read() in order
to get both function mode and direction atomically.

Fixes: f1d8a071 ("counter: 104-quad-8: Add Generic Counter interface support")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221020141121.15434-1-william.gray@linaro.org/


Signed-off-by: default avatarWilliam Breathitt Gray <william.gray@linaro.org>
      d501d378
    • William Breathitt Gray's avatar
      counter: microchip-tcb-capture: Handle Signal1 read and Synapse · d917a62a
      William Breathitt Gray authored 
      The signal_read(), action_read(), and action_write() callbacks have been
assuming Signal0 is requested without checking. This results in requests
for Signal1 returning data for Signal0. This patch fixes these
oversights by properly checking for the Signal's id in the respective
callbacks and handling accordingly based on the particular Signal
requested. The trig_inverted member of the mchp_tc_data is removed as
superfluous.

Fixes: 106b1041

 ("counter: Add microchip TCB capture counter")
Cc: stable@vger.kernel.org
Reviewed-by: default avatarKamel Bouhara <kamel.bouhara@bootlin.com>
Link: https://lore.kernel.org/r/20221018121014.7368-1-william.gray@linaro.org/


Signed-off-by: default avatarWilliam Breathitt Gray <william.gray@linaro.org>
      d917a62a
    • Greg Kroah-Hartman's avatar
      Merge tag 'iio-fixes-for-6.1a' of... · 39114b88
      Greg Kroah-Hartman authored 
      Merge tag 'iio-fixes-for-6.1a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus

Jonathan writes:
  "1st set of IIO fixes for the 6.1 cycle.

   Usual bunch of driver fixes + one set of fixes for driver bugs
   introduced by a core change to how buffer attributes are handled.

   - buffer attributes
     * Remove usage of IIO_CONST_ATTR() for buffer attributes in all drivers
       where this occurred as that broke wrapping code need to duplicate these
       for multiple buffer support. The minimal fix is moving to
       IIO_DEVICE_ATTR_RO() with separate _show() routines.  A cleanup of
       this code, preventing similar issues in future will follow next merge
       window.
   - tools/iio
     * Wrong handling of number of digits in the number 0.
   - adi,ltc2983
     * Avoid reallocating channels on each wake up from sleep by moving
       that step out of the ltc2983_setup() function.
   - microchip,mcp3911
     * Wrong ID bits + masking in debug prints.
     * Fix ARRAY_SIZE() vs sizeof() mix up.
     * Handle NULL return on trigger allocation failure correctly.
   - st,stm32-adc:
     * Ensure we initialize sampling time even when optional property not
       provided in DT. Internal channels require a minimum value that will
       not otherwise be set.
   - taos,tsl2583
     * Fix a double call of iio_device_unregister() via device managed and
       un-managed paths."

* tag 'iio-fixes-for-6.1a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio:
  iio: bmc150-accel-core: Fix unsafe buffer attributes
  iio: adxl367: Fix unsafe buffer attributes
  iio: adxl372: Fix unsafe buffer attributes
  iio: at91-sama5d2_adc: Fix unsafe buffer attributes
  iio: temperature: ltc2983: allocate iio channels once
  tools: iio: iio_utils: fix digit calculation
  iio: adc: stm32-adc: fix channel sampling time init
  iio: adc: mcp3911: mask out device ID in debug prints
  iio: adc: mcp3911: use correct id bits
  iio: adc: mcp3911: return proper error code on failure to allocate trigger
  iio: adc: mcp3911: fix sizeof() vs ARRAY_SIZE() bug
  iio: light: tsl2583: Fix module unloading
      39114b88
  5. Oct 22, 2022
  7. Oct 21, 2022
    • James Clark's avatar
      coresight: cti: Fix hang in cti_disable_hw() · 665c157e
      James Clark authored 
      cti_enable_hw() and cti_disable_hw() are called from an atomic context
so shouldn't use runtime PM because it can result in a sleep when
communicating with firmware.

Since commit 3c665633 ("Revert "firmware: arm_scmi: Add clock
management to the SCMI power domain""), this causes a hang on Juno when
running the Perf Coresight tests or running this command:

  perf record -e cs_etm//u -- ls

This was also missed until the revert commit because pm_runtime_put()
was called with the wrong device until commit 692c9a49 ("coresight:
cti: Correct the parameter for pm_runtime_put")

With lock and scheduler debugging enabled the following is output:

   coresight cti_sys0: cti_enable_hw -- dev:cti_sys0  parent: 20020000.cti
   BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151
   in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec
   preempt_count: 2, expected: 0
   RCU nest depth: 0, expected: 0
   INFO: lockdep is turned off.
   irq event stamp: 0
   hardirqs last  enabled at (0): [<0000000000000000>] 0x0
   hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948
   softirqs last  enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948
   softirqs last disabled at (0): [<0000000000000000>] 0x0
   CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7
   Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022
   Call trace:
    dump_backtrace+0x134/0x140
    show_stack+0x20/0x58
    dump_stack_lvl+0x8c/0xb8
    dump_stack+0x18/0x34
    __might_resched+0x180/0x228
    __might_sleep+0x50/0x88
    __pm_runtime_resume+0xac/0xb0
    cti_enable+0x44/0x120
    coresight_control_assoc_ectdev+0xc0/0x150
    coresight_enable_path+0xb4/0x288
    etm_event_start+0x138/0x170
    etm_event_add+0x48/0x70
    event_sched_in.isra.122+0xb4/0x280
    merge_sched_in+0x1fc/0x3d0
    visit_groups_merge.constprop.137+0x16c/0x4b0
    ctx_sched_in+0x114/0x1f0
    perf_event_sched_in+0x60/0x90
    ctx_resched+0x68/0xb0
    perf_event_exec+0x138/0x508
    begin_new_exec+0x52c/0xd40
    load_elf_binary+0x6b8/0x17d0
    bprm_execve+0x360/0x7f8
    do_execveat_common.isra.47+0x218/0x238
    __arm64_sys_execve+0x48/0x60
    invoke_syscall+0x4c/0x110
    el0_svc_common.constprop.4+0xfc/0x120
    do_el0_svc+0x34/0xc0
    el0_svc+0x40/0x98
    el0t_64_sync_handler+0x98/0xc0
    el0t_64_sync+0x170/0x174

Fix the issue by removing the runtime PM calls completely. They are not
needed here because it must have already been done when building the
path for a trace.

Fixes: 835d722b

 ("coresight: cti: Initial CoreSight CTI Driver")
Reported-by: default avatarAishwarya TCV <Aishwarya.TCV@arm.com>
Reported-by: default avatarCristian Marussi <Cristian.Marussi@arm.com>
Suggested-by: default avatarSuzuki Poulose <Suzuki.Poulose@arm.com>
Signed-off-by: default avatarJames Clark <james.clark@arm.com>
Reviewed-by: default avatarMike Leach <mike.leach@linaro.org>
Tested-by: default avatarMike Leach <mike.leach@linaro.org>
Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20221005131452.1506328-1-james.clark@arm.com
      665c157e
    • Sudeep Holla's avatar
      coresight: Fix possible deadlock with lock dependency · 23722fb4
      Sudeep Holla authored 
      With lockdeps enabled, we get the following warning:

======================================================
WARNING: possible circular locking dependency detected
------------------------------------------------------
kworker/u12:1/53 is trying to acquire lock:
ffff80000adce220 (coresight_mutex){+.+.}-{4:4}, at: coresight_set_assoc_ectdev_mutex+0x3c/0x5c
but task is already holding lock:
ffff80000add1f60 (ect_mutex){+.+.}-{4:4}, at: cti_probe+0x318/0x394

which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:

-> #1 (ect_mutex){+.+.}-{4:4}:
       __mutex_lock_common+0xd8/0xe60
       mutex_lock_nested+0x44/0x50
       cti_add_assoc_to_csdev+0x4c/0x184
       coresight_register+0x2f0/0x314
       tmc_probe+0x33c/0x414

-> #0 (coresight_mutex){+.+.}-{4:4}:
       __lock_acquire+0x1a20/0x32d0
       lock_acquire+0x160/0x308
       __mutex_lock_common+0xd8/0xe60
       mutex_lock_nested+0x44/0x50
       coresight_set_assoc_ectdev_mutex+0x3c/0x5c
       cti_update_conn_xrefs+0x6c/0xf8
       cti_probe+0x33c/0x394

other info that might help us debug this:
 Possible unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(ect_mutex);
                               lock(coresight_mutex);
                               lock(ect_mutex);
  lock(coresight_mutex);
 *** DEADLOCK ***

4 locks held by kworker/u12:1/53:
 #0: ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1fc/0x63c
 #1: (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x228/0x63c
 #2: (&dev->mutex){....}-{4:4}, at: __device_attach+0x48/0x1a8
 #3: (ect_mutex){+.+.}-{4:4}, at: cti_probe+0x318/0x394

To fix the same, call cti_add_assoc_to_csdev without the holding
coresight_mutex and confine the locking while setting the associated
ect / cti device using coresight_set_assoc_ectdev_mutex().

Fixes: 177af828

 ("coresight: cti: Enable CTI associated with devices")
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
Reviewed-by: default avatarMike Leach <mike.leach@linaro.org>
Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20220721130329.3787211-1-sudeep.holla@arm.com
      23722fb4
  9. Oct 17, 2022
  11. Oct 16, 2022
  13. Oct 15, 2022
    • Steve French's avatar
      smb3: improve SMB3 change notification support · e3e94634
      Steve French authored 
      

Change notification is a commonly supported feature by most servers,
but the current ioctl to request notification when a directory is
changed does not return the information about what changed
(even though it is returned by the server in the SMB3 change
notify response), it simply returns when there is a change.

This ioctl improves upon CIFS_IOC_NOTIFY by returning the notify
information structure which includes the name of the file(s) that
changed and why. See MS-SMB2 2.2.35 for details on the individual
filter flags and the file_notify_information structure returned.

To use this simply pass in the following (with enough space
to fit at least one file_notify_information structure)

struct __attribute__((__packed__)) smb3_notify {
       uint32_t completion_filter;
       bool     watch_tree;
       uint32_t data_len;
       uint8_t  data[];
} __packed;

using CIFS_IOC_NOTIFY_INFO 0xc009cf0b
 or equivalently _IOWR(CIFS_IOCTL_MAGIC, 11, struct smb3_notify_info)

The ioctl will block until the server detects a change to that
directory or its subdirectories (if watch_tree is set).

Acked-by: default avatarPaulo Alcantara (SUSE) <pc@cjr.nz>
Acked-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      e3e94634
    • Steve French's avatar
      cifs: lease key is uninitialized in two additional functions when smb1 · 2bff0659
      Steve French authored 
      

cifs_open and _cifsFileInfo_put also end up with lease_key uninitialized
in smb1 mounts.  It is cleaner to set lease key to zero in these
places where leases are not supported (smb1 can not return lease keys
so the field was uninitialized).

Addresses-Coverity: 1514207 ("Uninitialized scalar variable")
Addresses-Coverity: 1514331 ("Uninitialized scalar variable")
Reviewed-by: default avatarPaulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      2bff0659