RE: [PATCH v8 1/1] dmaengine: switchtec-dma: Introduce Switchtec DMA engine PCI driver

[Grochowski, Maciej]

Hi Kelvin,

I have noticed lockdep_rcu complaining about suspicious rcu_dereference inside: switchtec_dma_chans_enumerate and switchtec_dma_chan_free functions

In the switchtec_dma_chans_enumerate:
```
static int switchtec_dma_chans_enumerate(struct switchtec_dma_dev *swdma_dev,
                                          int chan_cnt)
 {
         struct dma_device *dma = &swdma_dev->dma_dev;
         struct pci_dev *pdev = rcu_dereference(swdma_dev->pdev);	<<< suspicious RCU usage
         int base;
         int cnt;
         int rc;
         int i;
```
And inside switchtec_dma_chan_free
```
static int switchtec_dma_chan_free(struct switchtec_dma_chan
 *swdma_chan) {
         struct pci_dev *pdev = rcu_dereference(swdma_chan->swdma_dev->pdev);  <<< suspicious RCU usage

         spin_lock_bh(&swdma_chan->submit_lock);
         swdma_chan->ring_active = false;
         spin_unlock_bh(&swdma_chan->submit_lock);
```

Is going to trigger lockdep_rcu below log from my system:
```
[  296.678725] =============================
[  296.682890] WARNING: suspicious RCU usage
[  296.687017] 6.8.0-rc4+ #2 Tainted: G            E
[  296.687028] -----------------------------
[  296.691166] drivers/dma/switchtec_dma.c:1256 suspicious rcu_dereference_check() usage!
[  296.699263]
               other info that might help us debug this:

[  296.707446]
               rcu_scheduler_active = 2, debug_locks = 1
[  296.714142] 1 lock held by insmod/1536:
[  296.714153]  #0: ffff8881191d91b0 (&dev->mutex){....}-{4:4}, at: __driver_attach+0x172/0x3b0
[  296.714207]
               stack backtrace:
[  296.718689] CPU: 45 PID: 1536 Comm: insmod Tainted: G            E      6.8.0-rc4+ #2
[  296.718710] Call Trace:
[  296.718720]  <TASK>
[  296.718731]  dump_stack_lvl+0xac/0xc0
[  296.718750]  lockdep_rcu_suspicious+0x1dd/0x380
[  296.718782]  switchtec_dma_probe+0xf0a/0x1400 [switchtec_dma]
[  296.718819]  ? _raw_spin_unlock_irqrestore+0x66/0x80
```

I think it should be also guarded by rcu_read_lock/unlock in order to avoid such situations.