On Tue, Apr 9, 2019 at 6:40 PM Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > On Mon, Apr 08, 2019 at 01:01:51PM +0100, Jonathan Cameron wrote: > > On Mon, 8 Apr 2019 13:34:37 +0300 > > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > On Mon, Apr 08, 2019 at 11:14:39AM +0100, Jonathan Cameron wrote: > > > > On Mon, 8 Apr 2019 13:01:21 +0300 > > > > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > > > On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote: > > > > > > On Mon, 8 Apr 2019 13:02:12 +1000 > > > > > > Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > > > > > > > That is the correct resolution. > > > > > > > > > > I think it still misses the following fix: > > > > > > > Is that actually a problem given it's copied over from buffer->scan_mask just after allocation? > > > > The two masks are the same length so I don't think we have a problem with this one. > > > > Am I missing something? > > > > > > Hmm... I didn't get why the commit 20ea39ef9f2f fixes anything. > > > > > Good point. I'm don't think it ever did. > > > > Alex, any thoughts? > Hey, This seems to have been in the context of our tree. We have this patch: https://github.com/analogdevicesinc/linux/commit/81d00795b1537 That removes bitmap_copy() . See here: https://github.com/analogdevicesinc/linux/commit/81d00795b1537#diff-0a87744ce945d2c1c89ea19f21fb35bbL397 This change is not upstreamed yet. I guess I am slowly going nuts with trying to sync multiple trees [ our master, upstream IIO & some internal temp-branches ]. To give a bit of background: we've noticed this weird behavior while testing a AD7193 chip with the AD7192 driver and some weird things were happening. At the time, this patch seemed easy to send upstream, so I sent it. Sorry for the noise. I guess the conclusion is, that in the context of the mainline IIO tree, commit 20ea39ef9f2f is not needed. Thanks Alex > I have a thought that it might be possible that somewhere code is still broken, > i.e. accessing bitmap behind the size (for example, iterating by unsigned long > without bitmap size being aligned to size of unsigned long). > > If this is a case, the mentioned patch has a symptomatic healing and not fixing > a root cause. > > -- > With Best Regards, > Andy Shevchenko > >
