Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support
On Fri, Mar 03, 2017 at 10:46:03AM -0800, Laura Abbott wrote:
> On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
> >> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
> >>> Now that we call dma_map in the dma_buf API callbacks there is no need
> >>> to use the existing cache APIs. Remove the sync ioctl and the existing
> >>> bad dma_sync calls. Explicit caching can be handled with the dma_buf
> >>> sync API.
> >>>
> >>> Signed-off-by: Laura Abbott
> >>> ---
> >>>
> >>> drivers/staging/android/ion/ion-ioctl.c | 5
> >>> drivers/staging/android/ion/ion.c | 40
> >>> drivers/staging/android/ion/ion_carveout_heap.c | 6
> >>> drivers/staging/android/ion/ion_chunk_heap.c| 6
> >>> drivers/staging/android/ion/ion_page_pool.c | 3 --
> >>> drivers/staging/android/ion/ion_system_heap.c | 5
> >>> 6 files changed, 65 deletions(-)
> >>>
> >>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
> >>> b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
> >>> --- a/drivers/staging/android/ion/ion-ioctl.c
> >>> +++ b/drivers/staging/android/ion/ion-ioctl.c
> >>> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
> >>> unsigned long arg)>
> >>> data.handle.handle = handle->id;
> >>>
> >>> break;
> >>>
> >>> }
> >>>
> >>> - case ION_IOC_SYNC:
> >>> - {
> >>> - ret = ion_sync_for_device(client, data.fd.fd);
> >>> - break;
> >>> - }
> >>
> >> You missed the case ION_IOC_SYNC: in compat_ion.c.
> >>
> >> While at it: Should we also remove the entire custom_ioctl infrastructure?
> >> It's entirely unused afaict, and for a pure buffer allocator I don't see
> >> any need to have custom ioctl.
> >
> > I second that, if you want to make ion a standard API, then we certainly
> > don't
> > want any custom ioctl.
> >
> >> More code to remove potentially:
> >> - The entire compat ioctl stuff - would be an abi break, but I guess if we
> >> pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
> >> would allow us to remove compat_ion.c entirely.
> >>
> >> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
> >> still need to be able to import anything. All the cache flushing/mapping
> >> is done through dma-buf ops/ioctls.
> >>
> >>
>
> Good point to all of the above. I was considering keeping the import around
> for backwards compatibility reasons but given how much other stuff is being
> potentially broken, everything should just get ripped out.
If you're ok with breaking the world, then I strongly suggest we go
through the uapi header and replace all types with the standard
fixed-width ones (__s32, __s64 and __u32, __u64). Allows us to remove all
the compat ioctl code :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly
On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote: > On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > > Hi Laura, > > > > Thank you for the patch. > > > > On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > >> When CMA was first introduced, its primary use was for DMA allocation > >> and the only way to get CMA memory was to call dma_alloc_coherent. This > >> put Ion in an awkward position since there was no device structure > >> readily available and setting one up messed up the coherency model. > >> These days, CMA can be allocated directly from the APIs. Switch to using > >> this model to avoid needing a dummy device. This also avoids awkward > >> caching questions. > > > > If the DMA mapping API isn't suitable for today's requirements anymore, I > > believe that's what needs to be fixed, instead of working around the > > problem > > by introducing another use-case-specific API. > > > > I don't think this is a usecase specific API. CMA has been decoupled from > DMA already because it's used in other places. The trying to go through > DMA was just another layer of abstraction, especially since there isn't > a device available for allocation. Also, we've had separation of allocation and dma-mapping since forever, that's how it works almost everywhere. Not exactly sure why/how arm-soc ecosystem ended up focused so much on dma_alloc_coherent. I think separating allocation from dma mapping/coherency is perfectly fine, and the way to go. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On Fri, Mar 03, 2017 at 06:45:40PM +0200, Laurent Pinchart wrote: > - I haven't seen any proposal how a heap-based solution could be used in a > generic distribution. This needs to be figured out before committing to any > API/ABI. Two replies from my side: - Just because a patch doesn't solve world hunger isn't really a good reason to reject it. - Heap doesn't mean its not resizeable (but I'm not sure that's really your concern). - Imo ION is very much part of the picture here to solve this for real. We need to bits: * Be able to allocate memory from specific pools, not going through a specific driver. ION gives us that interface. This is e.g. also needed for "special" memory, like SMA tries to expose. * Some way to figure out how&where to allocate the buffer object. This is purely a userspace problem, and this is the part the unix memory allocator tries to solve. There's no plans in there for big kernel changes, instead userspace does a dance to reconcile all the constraints, and one of the constraints might be "you have to allocate this from this special ION heap". The only thing the kernel needs to expose is which devices use which ION heaps (we kinda do that already), and maybe some hints of how they can be generalized (but I guess stuff like "minimal pagesize of x KB" is also fulfilled by any CMA heap is knowledge userspace needs). Again I think waiting for this to be fully implemented before we merge any part is going to just kill any upstreaming efforts. ION in itself, without the full buffer negotiation dance seems clearly useful (also for stuff like SMA), and having it merged will help with moving the buffer allocation dance forward. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On Mon, Mar 06, 2017 at 08:42:59AM +0100, Michal Hocko wrote: > On Fri 03-03-17 09:37:55, Laura Abbott wrote: > > On 03/03/2017 05:29 AM, Michal Hocko wrote: > > > On Thu 02-03-17 13:44:32, Laura Abbott wrote: > > >> Hi, > > >> > > >> There's been some recent discussions[1] about Ion-like frameworks. > > >> There's > > >> apparently interest in just keeping Ion since it works reasonablly well. > > >> This series does what should be the final clean ups for it to possibly be > > >> moved out of staging. > > >> > > >> This includes the following: > > >> - Some general clean up and removal of features that never got a lot of > > >> use > > >> as far as I can tell. > > >> - Fixing up the caching. This is the series I proposed back in > > >> December[2] > > >> but never heard any feedback on. It will certainly break existing > > >> applications that rely on the implicit caching. I'd rather make an > > >> effort > > >> to move to a model that isn't going directly against the establishement > > >> though. > > >> - Fixing up the platform support. The devicetree approach was never well > > >> recieved by DT maintainers. The proposal here is to think of Ion less > > >> as > > >> specifying requirements and more of a framework for exposing memory to > > >> userspace. > > >> - CMA allocations now happen without the need of a dummy device > > >> structure. > > >> This fixes a bunch of the reasons why I attempted to add devicetree > > >> support before. > > >> > > >> I've had problems getting feedback in the past so if I don't hear any > > >> major > > >> objections I'm going to send out with the RFC dropped to be picked up. > > >> The only reason there isn't a patch to come out of staging is to discuss > > >> any > > >> other changes to the ABI people might want. Once this comes out of > > >> staging, > > >> I really don't want to mess with the ABI. > > > > > > Could you recapitulate concerns preventing the code being merged > > > normally rather than through the staging tree and how they were > > > addressed? > > > > > > > Sorry, I'm really not understanding your question here, can you > > clarify? > > There must have been a reason why this code ended up in the staging > tree, right? So my question is what those reasons were and how they were > handled in order to move the code from the staging subtree. No one gave a thing about android in upstream, so Greg KH just dumped it all into staging/android/. We've discussed ION a bunch of times, recorded anything we'd like to fix in staging/android/TODO, and Laura's patch series here addresses a big chunk of that. This is pretty much the same approach we (gpu folks) used to de-stage the syncpt stuff. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote: > No one gave a thing about android in upstream, so Greg KH just dumped it > all into staging/android/. We've discussed ION a bunch of times, recorded > anything we'd like to fix in staging/android/TODO, and Laura's patch > series here addresses a big chunk of that. > This is pretty much the same approach we (gpu folks) used to de-stage the > syncpt stuff. Well, there's also the fact that quite a few people have issues with the design (like Laurent). It seems like a lot of them have either got more comfortable with it over time, or at least not managed to come up with any better ideas in the meantime. signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: media: platform: bcm2835 - Style fix
On Sun, Mar 05, 2017 at 10:43:19AM +1300, Derek Robson wrote: > On Sat, Mar 04, 2017 at 02:57:22PM +0300, Dan Carpenter wrote: > > Copy a patch prefix that everyone else has been using: > > > > git log --oneline drivers/staging/media/platform/bcm2835/ > > > > The subject is too vague as well. > > Is this what you are looking for? > > [patch] Staging: bcm2835: fixed style of block comments Yes. > And should I just re-send as a V2 with new subject? Yes. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging/vc04_services: initialize cache line size properly
On Wed, Mar 01, 2017 at 05:59:38PM -0800, Michael Zoran wrote: > Hi Arnd, > > I submitted a change which is in Linux-next now that makes the whole > CACHE_LINE_SIZE macro meaningless. It now always reads the size from > the DT and errors out with -ENODEV if the property is missing. > > I was going to submit a change to delete the macro completely, just > never got to it. > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit > /drivers/staging/vc04_services/interface?id=6cf1bf636a067eb308cb3a8322b > 9d6b1844a075d This should be in 4.11-rc1. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: bcm2835-audio: bcm2835-pcm: fix a brace coding style issue
On Wed, Mar 01, 2017 at 09:46:16PM +0100, Maciej Billewicz wrote: > Fix coding style issue. > > Signed-off-by: Maciej Billewicz > --- > drivers/staging/bcm2835-audio/bcm2835-pcm.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Does not apply to my tree, sorry :( greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: else is not generally useful after a break or return
Hi Arushi,
[auto build test WARNING on staging/staging-testing]
[cannot apply to v4.11-rc1 next-20170306]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Arushi-Singhal/staging-speakup-else-is-not-generally-useful-after-a-break-or-return/20170306-072009
config: openrisc-allmodconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All warnings (new ones prefixed by >>):
drivers/staging/speakup/keyhelp.c: In function 'spk_handle_help':
>> drivers/staging/speakup/keyhelp.c:146:19: warning: unused variable 'val'
>> drivers/staging/speakup/keyhelp.c:146:11: warning: unused variable 'p_keys'
>> drivers/staging/speakup/keyhelp.c:145:9: warning: unused variable 'func'
>> drivers/staging/speakup/keyhelp.c:143:9: warning: unused variable 'n'
vim +/val +146 drivers/staging/speakup/keyhelp.c
c6e3fd22c William Hubbs 2010-10-07 137 }
c6e3fd22c William Hubbs 2010-10-07 138 return 0;
c6e3fd22c William Hubbs 2010-10-07 139 }
c6e3fd22c William Hubbs 2010-10-07 140
ca2beaf84 Samuel Thibault 2013-01-02 141 int spk_handle_help(struct vc_data
*vc, u_char type, u_char ch, u_short key)
c6e3fd22c William Hubbs 2010-10-07 142 {
c6e3fd22c William Hubbs 2010-10-07 @143 int i, n;
c6e3fd22c William Hubbs 2010-10-07 144 char *name;
c6e3fd22c William Hubbs 2010-10-07 @145 u_char func, *kp;
c6e3fd22c William Hubbs 2010-10-07 @146 u_short *p_keys, val;
8e69a8110 Domagoj Trsan 2014-09-09 147
c6e3fd22c William Hubbs 2010-10-07 148 if (letter_offsets[0] == -1)
c6e3fd22c William Hubbs 2010-10-07 149 help_init();
:: The code at line 146 was first introduced by commit
:: c6e3fd22cd538365bfeb82997d5b89562e077d42 Staging: add speakup to the
staging directory
:: TO: William Hubbs
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH V4] staging: vchiq_arm: Add compatibility wrappers for ioctls
On Sat, Mar 04, 2017 at 06:57:50AM -0800, Michael Zoran wrote: > On Sat, 2017-03-04 at 14:58 +0300, Dan Carpenter wrote: > > On Wed, Mar 01, 2017 at 07:41:46PM -0800, Michael Zoran wrote: > > > Changes: > > > V1 - Complete rewrite of the ioctl code. > > > V2 - Rewrite of only ioctls that change > > > between 32 bit and 64 bit. > > > V3 - Minor changes. > > > V4(This Version) - Abandon cleaning up the > > > exising code and completely write the > > > wrappers on top of the native ioctls. > > > No existing lines are changed. > > > > I think I objected to earlier versions but this approach looks nice. > > > > regards, > > dan carpenter > > > > Cool, does this mean I get an ACK? > > It really would be good to get this in since it's one of the last major > missing pieces to get Raspbian to work with a 64 bit kernel. I'll be glad to take this if you respin it with the fixes that Eric asked for :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On Mon 06-03-17 11:40:41, Daniel Vetter wrote: > On Mon, Mar 06, 2017 at 08:42:59AM +0100, Michal Hocko wrote: > > On Fri 03-03-17 09:37:55, Laura Abbott wrote: > > > On 03/03/2017 05:29 AM, Michal Hocko wrote: > > > > On Thu 02-03-17 13:44:32, Laura Abbott wrote: > > > >> Hi, > > > >> > > > >> There's been some recent discussions[1] about Ion-like frameworks. > > > >> There's > > > >> apparently interest in just keeping Ion since it works reasonablly > > > >> well. > > > >> This series does what should be the final clean ups for it to possibly > > > >> be > > > >> moved out of staging. > > > >> > > > >> This includes the following: > > > >> - Some general clean up and removal of features that never got a lot > > > >> of use > > > >> as far as I can tell. > > > >> - Fixing up the caching. This is the series I proposed back in > > > >> December[2] > > > >> but never heard any feedback on. It will certainly break existing > > > >> applications that rely on the implicit caching. I'd rather make an > > > >> effort > > > >> to move to a model that isn't going directly against the > > > >> establishement > > > >> though. > > > >> - Fixing up the platform support. The devicetree approach was never > > > >> well > > > >> recieved by DT maintainers. The proposal here is to think of Ion > > > >> less as > > > >> specifying requirements and more of a framework for exposing memory > > > >> to > > > >> userspace. > > > >> - CMA allocations now happen without the need of a dummy device > > > >> structure. > > > >> This fixes a bunch of the reasons why I attempted to add devicetree > > > >> support before. > > > >> > > > >> I've had problems getting feedback in the past so if I don't hear any > > > >> major > > > >> objections I'm going to send out with the RFC dropped to be picked up. > > > >> The only reason there isn't a patch to come out of staging is to > > > >> discuss any > > > >> other changes to the ABI people might want. Once this comes out of > > > >> staging, > > > >> I really don't want to mess with the ABI. > > > > > > > > Could you recapitulate concerns preventing the code being merged > > > > normally rather than through the staging tree and how they were > > > > addressed? > > > > > > > > > > Sorry, I'm really not understanding your question here, can you > > > clarify? > > > > There must have been a reason why this code ended up in the staging > > tree, right? So my question is what those reasons were and how they were > > handled in order to move the code from the staging subtree. > > No one gave a thing about android in upstream, so Greg KH just dumped it > all into staging/android/. We've discussed ION a bunch of times, recorded > anything we'd like to fix in staging/android/TODO, and Laura's patch > series here addresses a big chunk of that. Thanks for the TODO reference. I was looking exactly at something like that in drivers/staging/android/ion/. To bad I didn't look one directory up. Thanks for the clarification! -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly
Hi Daniel, On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote: > On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote: > > On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > >> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > >>> When CMA was first introduced, its primary use was for DMA allocation > >>> and the only way to get CMA memory was to call dma_alloc_coherent. This > >>> put Ion in an awkward position since there was no device structure > >>> readily available and setting one up messed up the coherency model. > >>> These days, CMA can be allocated directly from the APIs. Switch to > >>> using this model to avoid needing a dummy device. This also avoids > >>> awkward caching questions. > >> > >> If the DMA mapping API isn't suitable for today's requirements anymore, > >> I believe that's what needs to be fixed, instead of working around the > >> problem by introducing another use-case-specific API. > > > > I don't think this is a usecase specific API. CMA has been decoupled from > > DMA already because it's used in other places. The trying to go through > > DMA was just another layer of abstraction, especially since there isn't > > a device available for allocation. > > Also, we've had separation of allocation and dma-mapping since forever, > that's how it works almost everywhere. Not exactly sure why/how arm-soc > ecosystem ended up focused so much on dma_alloc_coherent. I believe because that was the easy way to specify memory constraints. The API receives a device pointer and will allocate memory suitable for DMA for that device. The fact that it maps it to the device is a side-effect in my opinion. > I think separating allocation from dma mapping/coherency is perfectly > fine, and the way to go. Especially given that in many cases we'll want to share buffers between multiple devices, so we'll need to map them multiple times. My point still stands though, if we want to move towards a model where allocation and mapping are decoupled, we need an allocation function that takes constraints (possibly implemented with two layers, a constraint resolution layer on top of a pool/heap/type/foo-based allocator), and a mapping API. IOMMU handling being integrated in the DMA mapping API we're currently stuck with it, which might call for brushing up that API. -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Guten Tag
Hallo, Mein Name ist Joanna Diane Christopher. Ich bin die einzige Tochter von spät Dr. Fredrick Christopher. Mein Vater war ein vorzüglicher Öl- und Gasunternehmer, bevor er starb. Er hatte auch umfangreiche Investitionen in Immobilien, Agrar- und Bankensektoren. Meine Mutter starb mit meinen Geschwistern in einem schrecklichen Autounfall auf Yamoussoukro Express Weg, als ich ein kleines Kind war. Ich habe gebetet, bevor ich dich kontaktiere, und ich glaubte, dass du der richtige Mensch bist, dem Gott zugewiesen wurde, um mir aus meiner schrecklichen Situation zu helfen. Bitte, ich möchte, dass Ihre Unterstützung mir hilft, mein erbliches Geld in der Summe von 7,5 Millionen US-Dollar in Ihr Land zu transferieren, für Investment-Ventures unter Ihrer Obhut und Richtlinie, während ich mein Studium in Ihrem Land nach der Übertragung fortsetzen werde. Es ist mein Wunsch, in dein Land zu kommen, um meine Ausbildung voranzubringen, während du mein erbliches Geld investierst und verwaltest. Bitte, ich bin ein Waise und ich brauche deine Hilfe, um mein erbliches Geld in dein Land zu übertragen, ich brauche auch deine Hilfe, um eine schöne Schule in deinem Land zu sichern, wo ich mein Studium fortsetzen werde. Ich bin bereit, Ihnen einen erheblichen Betrag als Entschädigung für Ihre Bemühungen / Input nach der erfolgreichen Übertragung in Ihr nominiertes Konto anzubieten. Sobald ich Ihre Antwort bekomme, die darauf hinweist, dass Ihr Interesse, mir zu helfen, dieses Geld an Ihr Land zu übertragen, werde ich Ihnen alle notwendigen Informationen geben, die Sie benötigen, um auf das Übertragen des Geldes auf Ihr Konto vorzugehen. Ich glaubte, dass diese Transaktion innerhalb von wenigen Tagen abgeschlossen wird, zeigen Sie Ihr Interesse, um mich zu unterstützen. Ich wäre Ihnen sehr dankbar, wenn Sie mir nach dem Lesen dieser E-Mail antworten könnten. Bitte bin ich total verwirrt und traumatisiert hier. Ich bin streng in der bedränglichen Situation, und ich bin verzweifelt, von Ihnen zu hören, um meine Hoffnung und mein Vertrauen wieder herzustellen, dass Sie dort für mich sein werden, um mein Leben und mein erbliches Geld zu retten, das mein Vater mir vermachte, bevor er zu Tode vergiftet wurde Von seinem bösen und gierigen Geschäftspartner mit der Unterstützung seiner neidischen Brüder Vielen Dank für Ihre Zeit und Rücksicht. Ich erwarte deine schnelle, positive Antwort an deiner Bequemlichkeit. Freundliche Grüße, Joanna ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 00/29] drivers, mics refcount conversions
This series, for various different drivers, replaces atomic_t reference counters with the new refcount_t type and API (see include/linux/refcount.h). By doing this we prevent intentional or accidental underflows or overflows that can led to use-after-free vulnerabilities. The below patches are fully independent and can be cherry-picked separately*. Since we convert all kernel subsystems in the same fashion, resulting in about 300 patches, we have to group them for sending at least in some fashion to be manageable. Please excuse the long cc list. *with the exception of the media/vb2-related patches that depend on vb2_vmarea_handler.refcount conversions. Not run-time tested beyond booting and using kernel with refcount conversions for my daily work. If there are no objections to these patches, I think they can go via Greg's drivers tree, as he suggested before. Elena Reshetova (29): drivers, block: convert xen_blkif.refcnt from atomic_t to refcount_t drivers, firewire: convert fw_node.ref_count from atomic_t to refcount_t drivers, char: convert vma_data.refcnt from atomic_t to refcount_t drivers, connector: convert cn_callback_entry.refcnt from atomic_t to refcount_t drivers, md, bcache: convert cached_dev.count from atomic_t to refcount_t drivers, md: convert dm_cache_metadata.ref_count from atomic_t to refcount_t drivers, md: convert dm_dev_internal.count from atomic_t to refcount_t drivers, md: convert mddev.active from atomic_t to refcount_t drivers, md: convert table_device.count from atomic_t to refcount_t drivers, md: convert stripe_head.count from atomic_t to refcount_t drivers, media: convert cx88_core.refcount from atomic_t to refcount_t drivers, media: convert s2255_dev.num_channels from atomic_t to refcount_t drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t drivers, media: convert vb2_dc_buf.refcount from atomic_t to refcount_t drivers, media: convert vb2_dma_sg_buf.refcount from atomic_t to refcount_t drivers, media: convert vb2_vmalloc_buf.refcount from atomic_t to refcount_t drivers, pci: convert hv_pci_dev.refs from atomic_t to refcount_t drivers, s390: convert urdev.ref_count from atomic_t to refcount_t drivers, s390: convert lcs_reply.refcnt from atomic_t to refcount_t drivers, s390: convert qeth_reply.refcnt from atomic_t to refcount_t drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t drivers: convert vme_user_vma_priv.refcnt from atomic_t to refcount_t drivers: convert iblock_req.pending from atomic_t to refcount_t drivers, usb: convert ffs_data.ref from atomic_t to refcount_t drivers, usb: convert dev_data.count from atomic_t to refcount_t drivers, usb: convert ep_data.count from atomic_t to refcount_t drivers: convert sbd_duart.map_guard from atomic_t to refcount_t drivers, xen: convert grant_map.users from atomic_t to refcount_t drivers/block/xen-blkback/common.h | 7 +-- drivers/block/xen-blkback/xenbus.c | 2 +- drivers/char/mspec.c | 9 ++-- drivers/connector/cn_queue.c | 4 +- drivers/connector/connector.c | 2 +- drivers/firewire/core-topology.c | 2 +- drivers/firewire/core.h| 8 ++-- drivers/md/bcache/bcache.h | 7 +-- drivers/md/bcache/super.c | 6 +-- drivers/md/bcache/writeback.h | 2 +- drivers/md/dm-cache-metadata.c | 9 ++-- drivers/md/dm-table.c | 6 +-- drivers/md/dm.c| 12 +++-- drivers/md/dm.h| 3 +- drivers/md/md.c| 6 +-- drivers/md/md.h| 3 +- drivers/md/raid5-cache.c | 8 ++-- drivers/md/raid5.c | 66 +- drivers/md/raid5.h | 3 +- drivers/media/pci/cx88/cx88-cards.c| 2 +- drivers/media/pci/cx88/cx88-core.c | 4 +- drivers/media/pci/cx88/cx88.h | 3 +- drivers/media/usb/s2255/s2255drv.c | 21 drivers/media/v4l2-core/videobuf2-dma-contig.c | 11 +++-- drivers/media/v4l2-core/videobuf2-dma-sg.c | 11 +++-- drivers/media/v4l2-core/videobuf2-memops.c | 6 +-- drivers/media/v4l2-core/videobuf2-vmalloc.c| 11 +++-- drivers/pci/host/pci-hyperv.c | 9 ++-- drivers/s390/char/vmur.c | 8 ++-- drivers/s390/char/vmur.h | 4 +- drivers/s390/net/lcs.c | 8 ++-- drivers/s390/net/lcs.h | 3 +- drivers/s390/net/qeth_core.h | 3 +- drivers/s390/net/qeth_core_main.c | 8 ++-- drivers/
[PATCH 01/29] drivers, block: convert xen_blkif.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/block/xen-blkback/common.h | 7 ---
drivers/block/xen-blkback/xenbus.c | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/block/xen-blkback/common.h
b/drivers/block/xen-blkback/common.h
index dea61f6..2ccfd62 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -333,7 +334,7 @@ struct xen_blkif {
struct xen_vbd vbd;
/* Back pointer to the backend_info. */
struct backend_info *be;
- atomic_trefcnt;
+ refcount_t refcnt;
/* for barrier (drain) requests */
struct completion drain_complete;
atomic_tdrain;
@@ -386,10 +387,10 @@ struct pending_req {
(_v)->bdev->bd_part->nr_sects : \
get_capacity((_v)->bdev->bd_disk))
-#define xen_blkif_get(_b) (atomic_inc(&(_b)->refcnt))
+#define xen_blkif_get(_b) (refcount_inc(&(_b)->refcnt))
#define xen_blkif_put(_b) \
do {\
- if (atomic_dec_and_test(&(_b)->refcnt)) \
+ if (refcount_dec_and_test(&(_b)->refcnt)) \
schedule_work(&(_b)->free_work);\
} while (0)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index 8fe61b5..9f89be3 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -176,7 +176,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
return ERR_PTR(-ENOMEM);
blkif->domid = domid;
- atomic_set(&blkif->refcnt, 1);
+ refcount_set(&blkif->refcnt, 1);
init_completion(&blkif->drain_complete);
INIT_WORK(&blkif->free_work, xen_blkif_deferred_free);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 02/29] drivers, firewire: convert fw_node.ref_count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/firewire/core-topology.c | 2 +-
drivers/firewire/core.h | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/firewire/core-topology.c b/drivers/firewire/core-topology.c
index 0de8350..939d259 100644
--- a/drivers/firewire/core-topology.c
+++ b/drivers/firewire/core-topology.c
@@ -124,7 +124,7 @@ static struct fw_node *fw_node_create(u32 sid, int
port_count, int color)
node->initiated_reset = SELF_ID_PHY_INITIATOR(sid);
node->port_count = port_count;
- atomic_set(&node->ref_count, 1);
+ refcount_set(&node->ref_count, 1);
INIT_LIST_HEAD(&node->link);
return node;
diff --git a/drivers/firewire/core.h b/drivers/firewire/core.h
index e1480ff6..c07962e 100644
--- a/drivers/firewire/core.h
+++ b/drivers/firewire/core.h
@@ -12,7 +12,7 @@
#include
#include
-#include
+#include
struct device;
struct fw_card;
@@ -184,7 +184,7 @@ struct fw_node {
* local node to this node. */
u8 max_depth:4; /* Maximum depth to any leaf node */
u8 max_hops:4; /* Max hops in this sub tree */
- atomic_t ref_count;
+ refcount_t ref_count;
/* For serializing node topology into a list. */
struct list_head link;
@@ -197,14 +197,14 @@ struct fw_node {
static inline struct fw_node *fw_node_get(struct fw_node *node)
{
- atomic_inc(&node->ref_count);
+ refcount_inc(&node->ref_count);
return node;
}
static inline void fw_node_put(struct fw_node *node)
{
- if (atomic_dec_and_test(&node->ref_count))
+ if (refcount_dec_and_test(&node->ref_count))
kfree(node);
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 03/29] drivers, char: convert vma_data.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/char/mspec.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/char/mspec.c b/drivers/char/mspec.c
index a9c2fa3..7b75669 100644
--- a/drivers/char/mspec.c
+++ b/drivers/char/mspec.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -89,7 +90,7 @@ static int is_sn2;
* protect in fork case where multiple tasks share the vma_data.
*/
struct vma_data {
- atomic_t refcnt;/* Number of vmas sharing the data. */
+ refcount_t refcnt; /* Number of vmas sharing the data. */
spinlock_t lock;/* Serialize access to this structure. */
int count; /* Number of pages allocated. */
enum mspec_page_type type; /* Type of pages allocated. */
@@ -144,7 +145,7 @@ mspec_open(struct vm_area_struct *vma)
struct vma_data *vdata;
vdata = vma->vm_private_data;
- atomic_inc(&vdata->refcnt);
+ refcount_inc(&vdata->refcnt);
}
/*
@@ -162,7 +163,7 @@ mspec_close(struct vm_area_struct *vma)
vdata = vma->vm_private_data;
- if (!atomic_dec_and_test(&vdata->refcnt))
+ if (!refcount_dec_and_test(&vdata->refcnt))
return;
last_index = (vdata->vm_end - vdata->vm_start) >> PAGE_SHIFT;
@@ -274,7 +275,7 @@ mspec_mmap(struct file *file, struct vm_area_struct *vma,
vdata->vm_end = vma->vm_end;
vdata->type = type;
spin_lock_init(&vdata->lock);
- atomic_set(&vdata->refcnt, 1);
+ refcount_set(&vdata->refcnt, 1);
vma->vm_private_data = vdata;
vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 04/29] drivers, connector: convert cn_callback_entry.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/connector/cn_queue.c | 4 ++--
drivers/connector/connector.c | 2 +-
include/linux/connector.h | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
index 1f8bf05..9c54fdf 100644
--- a/drivers/connector/cn_queue.c
+++ b/drivers/connector/cn_queue.c
@@ -45,7 +45,7 @@ cn_queue_alloc_callback_entry(struct cn_queue_dev *dev, const
char *name,
return NULL;
}
- atomic_set(&cbq->refcnt, 1);
+ refcount_set(&cbq->refcnt, 1);
atomic_inc(&dev->refcnt);
cbq->pdev = dev;
@@ -58,7 +58,7 @@ cn_queue_alloc_callback_entry(struct cn_queue_dev *dev, const
char *name,
void cn_queue_release_callback(struct cn_callback_entry *cbq)
{
- if (!atomic_dec_and_test(&cbq->refcnt))
+ if (!refcount_dec_and_test(&cbq->refcnt))
return;
atomic_dec(&cbq->pdev->refcnt);
diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 25693b0..8615594b 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -157,7 +157,7 @@ static int cn_call_callback(struct sk_buff *skb)
spin_lock_bh(&dev->cbdev->queue_lock);
list_for_each_entry(i, &dev->cbdev->queue_list, callback_entry) {
if (cn_cb_equal(&i->id.id, &msg->id)) {
- atomic_inc(&i->refcnt);
+ refcount_inc(&i->refcnt);
cbq = i;
break;
}
diff --git a/include/linux/connector.h b/include/linux/connector.h
index f8fe863..032102b 100644
--- a/include/linux/connector.h
+++ b/include/linux/connector.h
@@ -22,7 +22,7 @@
#define __CONNECTOR_H
-#include
+#include
#include
#include
@@ -49,7 +49,7 @@ struct cn_callback_id {
struct cn_callback_entry {
struct list_head callback_entry;
- atomic_t refcnt;
+ refcount_t refcnt;
struct cn_queue_dev *pdev;
struct cn_callback_id id;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 05/29] drivers, md, bcache: convert cached_dev.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/bcache/bcache.h| 7 ---
drivers/md/bcache/super.c | 6 +++---
drivers/md/bcache/writeback.h | 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
index c3ea03c..de2be28 100644
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -184,6 +184,7 @@
#include
#include
#include
+#include
#include
#include
@@ -299,7 +300,7 @@ struct cached_dev {
struct semaphoresb_write_mutex;
/* Refcount on the cache set. Always nonzero when we're caching. */
- atomic_tcount;
+ refcount_t count;
struct work_struct detach;
/*
@@ -805,13 +806,13 @@ do {
\
static inline void cached_dev_put(struct cached_dev *dc)
{
- if (atomic_dec_and_test(&dc->count))
+ if (refcount_dec_and_test(&dc->count))
schedule_work(&dc->detach);
}
static inline bool cached_dev_get(struct cached_dev *dc)
{
- if (!atomic_inc_not_zero(&dc->count))
+ if (!refcount_inc_not_zero(&dc->count))
return false;
/* Paired with the mb in cached_dev_attach */
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 85e3f21..cc36ce4 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -891,7 +891,7 @@ static void cached_dev_detach_finish(struct work_struct *w)
closure_init_stack(&cl);
BUG_ON(!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags));
- BUG_ON(atomic_read(&dc->count));
+ BUG_ON(refcount_read(&dc->count));
mutex_lock(&bch_register_lock);
@@ -1018,7 +1018,7 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct
cache_set *c)
* dc->c must be set before dc->count != 0 - paired with the mb in
* cached_dev_get()
*/
- atomic_set(&dc->count, 1);
+ refcount_set(&dc->count, 1);
/* Block writeback thread, but spawn it */
down_write(&dc->writeback_lock);
@@ -1030,7 +1030,7 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct
cache_set *c)
if (BDEV_STATE(&dc->sb) == BDEV_STATE_DIRTY) {
bch_sectors_dirty_init(dc);
atomic_set(&dc->has_dirty, 1);
- atomic_inc(&dc->count);
+ refcount_inc(&dc->count);
bch_writeback_queue(dc);
}
diff --git a/drivers/md/bcache/writeback.h b/drivers/md/bcache/writeback.h
index 629bd1a..5bac1b0 100644
--- a/drivers/md/bcache/writeback.h
+++ b/drivers/md/bcache/writeback.h
@@ -70,7 +70,7 @@ static inline void bch_writeback_add(struct cached_dev *dc)
{
if (!atomic_read(&dc->has_dirty) &&
!atomic_xchg(&dc->has_dirty, 1)) {
- atomic_inc(&dc->count);
+ refcount_inc(&dc->count);
if (BDEV_STATE(&dc->sb) != BDEV_STATE_DIRTY) {
SET_BDEV_STATE(&dc->sb, BDEV_STATE_DIRTY);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/md.c | 6 +++---
drivers/md/md.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 985374f..94c8ebf 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -449,7 +449,7 @@ EXPORT_SYMBOL(md_unplug);
static inline struct mddev *mddev_get(struct mddev *mddev)
{
- atomic_inc(&mddev->active);
+ refcount_inc(&mddev->active);
return mddev;
}
@@ -459,7 +459,7 @@ static void mddev_put(struct mddev *mddev)
{
struct bio_set *bs = NULL;
- if (!atomic_dec_and_lock(&mddev->active, &all_mddevs_lock))
+ if (!refcount_dec_and_lock(&mddev->active, &all_mddevs_lock))
return;
if (!mddev->raid_disks && list_empty(&mddev->disks) &&
mddev->ctime == 0 && !mddev->hold_active) {
@@ -495,7 +495,7 @@ void mddev_init(struct mddev *mddev)
INIT_LIST_HEAD(&mddev->all_mddevs);
setup_timer(&mddev->safemode_timer, md_safemode_timeout,
(unsigned long) mddev);
- atomic_set(&mddev->active, 1);
+ refcount_set(&mddev->active, 1);
atomic_set(&mddev->openers, 0);
atomic_set(&mddev->active_io, 0);
spin_lock_init(&mddev->lock);
diff --git a/drivers/md/md.h b/drivers/md/md.h
index b8859cb..4811663 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -360,7 +361,7 @@ struct mddev {
*/
struct mutexopen_mutex;
struct mutexreconfig_mutex;
- atomic_tactive; /* general refcount */
+ refcount_t active; /* general refcount */
atomic_topeners;/* number of active
opens */
int changed;/* True if we might
need to
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 06/29] drivers, md: convert dm_cache_metadata.ref_count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/dm-cache-metadata.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-cache-metadata.c b/drivers/md/dm-cache-metadata.c
index e4c2c1a..6d26e71 100644
--- a/drivers/md/dm-cache-metadata.c
+++ b/drivers/md/dm-cache-metadata.c
@@ -13,6 +13,7 @@
#include "persistent-data/dm-transaction-manager.h"
#include
+#include
/**/
@@ -102,7 +103,7 @@ struct cache_disk_superblock {
} __packed;
struct dm_cache_metadata {
- atomic_t ref_count;
+ refcount_t ref_count;
struct list_head list;
unsigned version;
@@ -756,7 +757,7 @@ static struct dm_cache_metadata *metadata_open(struct
block_device *bdev,
}
cmd->version = metadata_version;
- atomic_set(&cmd->ref_count, 1);
+ refcount_set(&cmd->ref_count, 1);
init_rwsem(&cmd->root_lock);
cmd->bdev = bdev;
cmd->data_block_size = data_block_size;
@@ -794,7 +795,7 @@ static struct dm_cache_metadata *lookup(struct block_device
*bdev)
list_for_each_entry(cmd, &table, list)
if (cmd->bdev == bdev) {
- atomic_inc(&cmd->ref_count);
+ refcount_inc(&cmd->ref_count);
return cmd;
}
@@ -865,7 +866,7 @@ struct dm_cache_metadata *dm_cache_metadata_open(struct
block_device *bdev,
void dm_cache_metadata_close(struct dm_cache_metadata *cmd)
{
- if (atomic_dec_and_test(&cmd->ref_count)) {
+ if (refcount_dec_and_test(&cmd->ref_count)) {
mutex_lock(&table_lock);
list_del(&cmd->list);
mutex_unlock(&table_lock);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 09/29] drivers, md: convert table_device.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/dm.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 9f37d7f..cba91c3 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define DM_MSG_PREFIX "core"
@@ -96,7 +97,7 @@ struct dm_md_mempools {
struct table_device {
struct list_head list;
- atomic_t count;
+ refcount_t count;
struct dm_dev dm_dev;
};
@@ -680,10 +681,11 @@ int dm_get_table_device(struct mapped_device *md, dev_t
dev, fmode_t mode,
format_dev_t(td->dm_dev.name, dev);
- atomic_set(&td->count, 0);
+ refcount_set(&td->count, 1);
list_add(&td->list, &md->table_devices);
+ } else {
+ refcount_inc(&td->count);
}
- atomic_inc(&td->count);
mutex_unlock(&md->table_devices_lock);
*result = &td->dm_dev;
@@ -696,7 +698,7 @@ void dm_put_table_device(struct mapped_device *md, struct
dm_dev *d)
struct table_device *td = container_of(d, struct table_device, dm_dev);
mutex_lock(&md->table_devices_lock);
- if (atomic_dec_and_test(&td->count)) {
+ if (refcount_dec_and_test(&td->count)) {
close_table_device(td, md);
list_del(&td->list);
kfree(td);
@@ -713,7 +715,7 @@ static void free_table_devices(struct list_head *devices)
struct table_device *td = list_entry(tmp, struct table_device,
list);
DMWARN("dm_destroy: %s still exists with %d references",
- td->dm_dev.name, atomic_read(&td->count));
+ td->dm_dev.name, refcount_read(&td->count));
kfree(td);
}
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/raid5-cache.c | 8 +++---
drivers/md/raid5.c | 66
drivers/md/raid5.h | 3 ++-
3 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 3f307be..6c05e12 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -979,7 +979,7 @@ int r5l_write_stripe(struct r5l_log *log, struct
stripe_head *sh)
* don't delay.
*/
clear_bit(STRIPE_DELAYED, &sh->state);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
mutex_lock(&log->io_mutex);
/* meta + data */
@@ -1321,7 +1321,7 @@ static void r5c_flush_stripe(struct r5conf *conf, struct
stripe_head *sh)
assert_spin_locked(&conf->device_lock);
list_del_init(&sh->lru);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
set_bit(STRIPE_HANDLE, &sh->state);
atomic_inc(&conf->active_stripes);
@@ -1424,7 +1424,7 @@ static void r5c_do_reclaim(struct r5conf *conf)
*/
if (!list_empty(&sh->lru) &&
!test_bit(STRIPE_HANDLE, &sh->state) &&
- atomic_read(&sh->count) == 0) {
+ refcount_read(&sh->count) == 0) {
r5c_flush_stripe(conf, sh);
if (count++ >= R5C_RECLAIM_STRIPE_GROUP)
break;
@@ -2650,7 +2650,7 @@ r5c_cache_data(struct r5l_log *log, struct stripe_head
*sh,
* don't delay.
*/
clear_bit(STRIPE_DELAYED, &sh->state);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
mutex_lock(&log->io_mutex);
/* meta + data */
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 2ce23b0..30c96a8 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -296,7 +296,7 @@ static void do_release_stripe(struct r5conf *conf, struct
stripe_head *sh,
static void __release_stripe(struct r5conf *conf, struct stripe_head *sh,
struct list_head *temp_inactive_list)
{
- if (atomic_dec_and_test(&sh->count))
+ if (refcount_dec_and_test(&sh->count))
do_release_stripe(conf, sh, temp_inactive_list);
}
@@ -388,7 +388,7 @@ void raid5_release_stripe(struct stripe_head *sh)
/* Avoid release_list until the last reference.
*/
- if (atomic_add_unless(&sh->count, -1, 1))
+ if (refcount_dec_not_one(&sh->count))
return;
if (unlikely(!conf->mddev->thread) ||
@@ -401,7 +401,7 @@ void raid5_release_stripe(struct stripe_head *sh)
slow_path:
local_irq_save(flags);
/* we are ok here if STRIPE_ON_RELEASE_LIST is set or not */
- if (atomic_dec_and_lock(&sh->count, &conf->device_lock)) {
+ if (refcount_dec_and_lock(&sh->count, &conf->device_lock)) {
INIT_LIST_HEAD(&list);
hash = sh->hash_lock_index;
do_release_stripe(conf, sh, &list);
@@ -491,7 +491,7 @@ static void init_stripe(struct stripe_head *sh, sector_t
sector, int previous)
struct r5conf *conf = sh->raid_conf;
int i, seq;
- BUG_ON(atomic_read(&sh->count) != 0);
+ BUG_ON(refcount_read(&sh->count) != 0);
BUG_ON(test_bit(STRIPE_HANDLE, &sh->state));
BUG_ON(stripe_operations_active(sh));
BUG_ON(sh->batch_head);
@@ -668,11 +668,11 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t
sector,
&conf->cache_state);
} else {
init_stripe(sh, sector, previous);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
}
- } else if (!atomic_inc_not_zero(&sh->count)) {
+ } else if (!refcount_inc_not_zero(&sh->count)) {
spin_lock(&conf->device_lock);
- if (!atomic_read(&sh->count)) {
+ if (!refcount_read(&sh->count)) {
if (!test_bit(STRIPE_HANDLE, &sh->state))
atomic_inc(&conf->active_stripes);
BUG_ON(list_empty(&sh->lru) &&
@@ -688,7 +688,7 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t
sector,
sh->group = NULL;
}
}
- atomic_inc(&sh->count);
+
[PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/pci/cx88/cx88-cards.c | 2 +-
drivers/media/pci/cx88/cx88-core.c | 4 ++--
drivers/media/pci/cx88/cx88.h | 3 ++-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/media/pci/cx88/cx88-cards.c
b/drivers/media/pci/cx88/cx88-cards.c
index cdfbde2..7fc5f5f 100644
--- a/drivers/media/pci/cx88/cx88-cards.c
+++ b/drivers/media/pci/cx88/cx88-cards.c
@@ -3670,7 +3670,7 @@ struct cx88_core *cx88_core_create(struct pci_dev *pci,
int nr)
if (!core)
return NULL;
- atomic_inc(&core->refcount);
+ refcount_set(&core->refcount, 1);
core->pci_bus = pci->bus->number;
core->pci_slot = PCI_SLOT(pci->devfn);
core->pci_irqmask = PCI_INT_RISC_RD_BERRINT | PCI_INT_RISC_WR_BERRINT |
diff --git a/drivers/media/pci/cx88/cx88-core.c
b/drivers/media/pci/cx88/cx88-core.c
index 973a9cd4..8bfa5b7 100644
--- a/drivers/media/pci/cx88/cx88-core.c
+++ b/drivers/media/pci/cx88/cx88-core.c
@@ -1052,7 +1052,7 @@ struct cx88_core *cx88_core_get(struct pci_dev *pci)
mutex_unlock(&devlist);
return NULL;
}
- atomic_inc(&core->refcount);
+ refcount_inc(&core->refcount);
mutex_unlock(&devlist);
return core;
}
@@ -1073,7 +1073,7 @@ void cx88_core_put(struct cx88_core *core, struct pci_dev
*pci)
release_mem_region(pci_resource_start(pci, 0),
pci_resource_len(pci, 0));
- if (!atomic_dec_and_test(&core->refcount))
+ if (!refcount_dec_and_test(&core->refcount))
return;
mutex_lock(&devlist);
diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index 115414c..16c1313 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -339,7 +340,7 @@ struct cx8802_dev;
struct cx88_core {
struct list_head devlist;
- atomic_t refcount;
+ refcount_t refcount;
/* board name */
intnr;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 07/29] drivers, md: convert dm_dev_internal.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/md/dm-table.c | 6 +++---
drivers/md/dm.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 3ad16d9..d2e2741 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -416,15 +416,15 @@ int dm_get_device(struct dm_target *ti, const char *path,
fmode_t mode,
return r;
}
- atomic_set(&dd->count, 0);
+ refcount_set(&dd->count, 1);
list_add(&dd->list, &t->devices);
} else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) {
r = upgrade_mode(dd, mode, t->md);
if (r)
return r;
+ refcount_inc(&dd->count);
}
- atomic_inc(&dd->count);
*result = dd->dm_dev;
return 0;
@@ -478,7 +478,7 @@ void dm_put_device(struct dm_target *ti, struct dm_dev *d)
dm_device_name(ti->table->md), d->name);
return;
}
- if (atomic_dec_and_test(&dd->count)) {
+ if (refcount_dec_and_test(&dd->count)) {
dm_put_table_device(ti->table->md, d);
list_del(&dd->list);
kfree(dd);
diff --git a/drivers/md/dm.h b/drivers/md/dm.h
index f298b01..63b8142 100644
--- a/drivers/md/dm.h
+++ b/drivers/md/dm.h
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "dm-stats.h"
@@ -38,7 +39,7 @@
*/
struct dm_dev_internal {
struct list_head list;
- atomic_t count;
+ refcount_t count;
struct dm_dev *dm_dev;
};
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 12/29] drivers, media: convert s2255_dev.num_channels from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/usb/s2255/s2255drv.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/s2255/s2255drv.c
b/drivers/media/usb/s2255/s2255drv.c
index a9d4484..2b4b009 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -256,7 +257,7 @@ struct s2255_vc {
struct s2255_dev {
struct s2255_vc vc[MAX_CHANNELS];
struct v4l2_device v4l2_dev;
- atomic_tnum_channels;
+ refcount_tnum_channels;
int frames;
struct mutexlock; /* channels[].vdev.lock */
struct mutexcmdlock; /* protects cmdbuf */
@@ -1581,11 +1582,11 @@ static void s2255_video_device_release(struct
video_device *vdev)
container_of(vdev, struct s2255_vc, vdev);
dprintk(dev, 4, "%s, chnls: %d\n", __func__,
- atomic_read(&dev->num_channels));
+ refcount_read(&dev->num_channels));
v4l2_ctrl_handler_free(&vc->hdl);
- if (atomic_dec_and_test(&dev->num_channels))
+ if (refcount_dec_and_test(&dev->num_channels))
s2255_destroy(dev);
return;
}
@@ -1688,7 +1689,7 @@ static int s2255_probe_v4l(struct s2255_dev *dev)
"failed to register video device!\n");
break;
}
- atomic_inc(&dev->num_channels);
+ refcount_set(&dev->num_channels, 1);
v4l2_info(&dev->v4l2_dev, "V4L2 device registered as %s\n",
video_device_node_name(&vc->vdev));
@@ -1696,11 +1697,11 @@ static int s2255_probe_v4l(struct s2255_dev *dev)
pr_info("Sensoray 2255 V4L driver Revision: %s\n",
S2255_VERSION);
/* if no channels registered, return error and probe will fail*/
- if (atomic_read(&dev->num_channels) == 0) {
+ if (refcount_read(&dev->num_channels) == 0) {
v4l2_device_unregister(&dev->v4l2_dev);
return ret;
}
- if (atomic_read(&dev->num_channels) != MAX_CHANNELS)
+ if (refcount_read(&dev->num_channels) != MAX_CHANNELS)
pr_warn("s2255: Not all channels available.\n");
return 0;
}
@@ -2248,7 +2249,7 @@ static int s2255_probe(struct usb_interface *interface,
goto errorFWDATA1;
}
- atomic_set(&dev->num_channels, 0);
+ refcount_set(&dev->num_channels, 0);
dev->pid = id->idProduct;
dev->fw_data = kzalloc(sizeof(struct s2255_fw), GFP_KERNEL);
if (!dev->fw_data)
@@ -2368,12 +2369,12 @@ static void s2255_disconnect(struct usb_interface
*interface)
{
struct s2255_dev *dev = to_s2255_dev(usb_get_intfdata(interface));
int i;
- int channels = atomic_read(&dev->num_channels);
+ int channels = refcount_read(&dev->num_channels);
mutex_lock(&dev->lock);
v4l2_device_disconnect(&dev->v4l2_dev);
mutex_unlock(&dev->lock);
/*see comments in the uvc_driver.c usb disconnect function */
- atomic_inc(&dev->num_channels);
+ refcount_inc(&dev->num_channels);
/* unregister each video device. */
for (i = 0; i < channels; i++)
video_unregister_device(&dev->vc[i].vdev);
@@ -2386,7 +2387,7 @@ static void s2255_disconnect(struct usb_interface
*interface)
dev->vc[i].vidstatus_ready = 1;
wake_up(&dev->vc[i].wait_vidstatus);
}
- if (atomic_dec_and_test(&dev->num_channels))
+ if (refcount_dec_and_test(&dev->num_channels))
s2255_destroy(dev);
dev_info(&interface->dev, "%s\n", __func__);
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/v4l2-core/videobuf2-memops.c | 6 +++---
include/media/videobuf2-memops.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c
b/drivers/media/v4l2-core/videobuf2-memops.c
index 1cd322e..4bb8424 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -96,10 +96,10 @@ static void vb2_common_vm_open(struct vm_area_struct *vma)
struct vb2_vmarea_handler *h = vma->vm_private_data;
pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
- __func__, h, atomic_read(h->refcount), vma->vm_start,
+ __func__, h, refcount_read(h->refcount), vma->vm_start,
vma->vm_end);
- atomic_inc(h->refcount);
+ refcount_inc(h->refcount);
}
/**
@@ -114,7 +114,7 @@ static void vb2_common_vm_close(struct vm_area_struct *vma)
struct vb2_vmarea_handler *h = vma->vm_private_data;
pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
- __func__, h, atomic_read(h->refcount), vma->vm_start,
+ __func__, h, refcount_read(h->refcount), vma->vm_start,
vma->vm_end);
h->put(h->arg);
diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
index 36565c7a..a6ed091 100644
--- a/include/media/videobuf2-memops.h
+++ b/include/media/videobuf2-memops.h
@@ -16,6 +16,7 @@
#include
#include
+#include
/**
* struct vb2_vmarea_handler - common vma refcount tracking handler
@@ -25,7 +26,7 @@
* @arg: argument for @put callback
*/
struct vb2_vmarea_handler {
- atomic_t*refcount;
+ refcount_t *refcount;
void(*put)(void *arg);
void*arg;
};
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 17/29] drivers, pci: convert hv_pci_dev.refs from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/pci/host/pci-hyperv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index cd114c6..870deed 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -56,6 +56,7 @@
#include
#include
#include
+#include
#include
/*
@@ -421,7 +422,7 @@ enum hv_pcidev_ref_reason {
struct hv_pci_dev {
/* List protected by pci_rescan_remove_lock */
struct list_head list_entry;
- atomic_t refs;
+ refcount_t refs;
enum hv_pcichild_state state;
struct pci_function_description desc;
bool reported_missing;
@@ -1254,13 +1255,13 @@ static void q_resource_requirements(void *context,
struct pci_response *resp,
static void get_pcichild(struct hv_pci_dev *hpdev,
enum hv_pcidev_ref_reason reason)
{
- atomic_inc(&hpdev->refs);
+ refcount_inc(&hpdev->refs);
}
static void put_pcichild(struct hv_pci_dev *hpdev,
enum hv_pcidev_ref_reason reason)
{
- if (atomic_dec_and_test(&hpdev->refs))
+ if (refcount_dec_and_test(&hpdev->refs))
kfree(hpdev);
}
@@ -1314,7 +1315,7 @@ static struct hv_pci_dev *new_pcichild_device(struct
hv_pcibus_device *hbus,
wait_for_completion(&comp_pkt.host_event);
hpdev->desc = *desc;
- get_pcichild(hpdev, hv_pcidev_ref_initial);
+ refcount_set(&hpdev->refs, 1);
get_pcichild(hpdev, hv_pcidev_ref_childlist);
spin_lock_irqsave(&hbus->device_list_lock, flags);
list_add_tail(&hpdev->list_entry, &hbus->children);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 15/29] drivers, media: convert vb2_dma_sg_buf.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index ecff8f4..29fde1a 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -46,7 +47,7 @@ struct vb2_dma_sg_buf {
struct sg_table *dma_sgt;
size_t size;
unsigned intnum_pages;
- atomic_trefcount;
+ refcount_t refcount;
struct vb2_vmarea_handler handler;
struct dma_buf_attachment *db_attach;
@@ -150,7 +151,7 @@ static void *vb2_dma_sg_alloc(struct device *dev, unsigned
long dma_attrs,
buf->handler.put = vb2_dma_sg_put;
buf->handler.arg = buf;
- atomic_inc(&buf->refcount);
+ refcount_set(&buf->refcount, 1);
dprintk(1, "%s: Allocated buffer of %d pages\n",
__func__, buf->num_pages);
@@ -176,7 +177,7 @@ static void vb2_dma_sg_put(void *buf_priv)
struct sg_table *sgt = &buf->sg_table;
int i = buf->num_pages;
- if (atomic_dec_and_test(&buf->refcount)) {
+ if (refcount_dec_and_test(&buf->refcount)) {
dprintk(1, "%s: Freeing buffer of %d pages\n", __func__,
buf->num_pages);
dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
@@ -320,7 +321,7 @@ static unsigned int vb2_dma_sg_num_users(void *buf_priv)
{
struct vb2_dma_sg_buf *buf = buf_priv;
- return atomic_read(&buf->refcount);
+ return refcount_read(&buf->refcount);
}
static int vb2_dma_sg_mmap(void *buf_priv, struct vm_area_struct *vma)
@@ -530,7 +531,7 @@ static struct dma_buf *vb2_dma_sg_get_dmabuf(void
*buf_priv, unsigned long flags
return NULL;
/* dmabuf keeps reference to vb2 buffer */
- atomic_inc(&buf->refcount);
+ refcount_inc(&buf->refcount);
return dbuf;
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 16/29] drivers, media: convert vb2_vmalloc_buf.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/v4l2-core/videobuf2-vmalloc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index 3f77814..f83253a 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -26,7 +27,7 @@ struct vb2_vmalloc_buf {
struct frame_vector *vec;
enum dma_data_direction dma_dir;
unsigned long size;
- atomic_trefcount;
+ refcount_t refcount;
struct vb2_vmarea_handler handler;
struct dma_buf *dbuf;
};
@@ -56,7 +57,7 @@ static void *vb2_vmalloc_alloc(struct device *dev, unsigned
long attrs,
return ERR_PTR(-ENOMEM);
}
- atomic_inc(&buf->refcount);
+ refcount_set(&buf->refcount, 1);
return buf;
}
@@ -64,7 +65,7 @@ static void vb2_vmalloc_put(void *buf_priv)
{
struct vb2_vmalloc_buf *buf = buf_priv;
- if (atomic_dec_and_test(&buf->refcount)) {
+ if (refcount_dec_and_test(&buf->refcount)) {
vfree(buf->vaddr);
kfree(buf);
}
@@ -161,7 +162,7 @@ static void *vb2_vmalloc_vaddr(void *buf_priv)
static unsigned int vb2_vmalloc_num_users(void *buf_priv)
{
struct vb2_vmalloc_buf *buf = buf_priv;
- return atomic_read(&buf->refcount);
+ return refcount_read(&buf->refcount);
}
static int vb2_vmalloc_mmap(void *buf_priv, struct vm_area_struct *vma)
@@ -368,7 +369,7 @@ static struct dma_buf *vb2_vmalloc_get_dmabuf(void
*buf_priv, unsigned long flag
return NULL;
/* dmabuf keeps reference to vb2 buffer */
- atomic_inc(&buf->refcount);
+ refcount_inc(&buf->refcount);
return dbuf;
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 14/29] drivers, media: convert vb2_dc_buf.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index fb6a177..d29a07f 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -34,7 +35,7 @@ struct vb2_dc_buf {
/* MMAP related */
struct vb2_vmarea_handler handler;
- atomic_trefcount;
+ refcount_t refcount;
struct sg_table *sgt_base;
/* DMABUF related */
@@ -86,7 +87,7 @@ static unsigned int vb2_dc_num_users(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
- return atomic_read(&buf->refcount);
+ return refcount_read(&buf->refcount);
}
static void vb2_dc_prepare(void *buf_priv)
@@ -122,7 +123,7 @@ static void vb2_dc_put(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
- if (!atomic_dec_and_test(&buf->refcount))
+ if (!refcount_dec_and_test(&buf->refcount))
return;
if (buf->sgt_base) {
@@ -170,7 +171,7 @@ static void *vb2_dc_alloc(struct device *dev, unsigned long
attrs,
buf->handler.put = vb2_dc_put;
buf->handler.arg = buf;
- atomic_inc(&buf->refcount);
+ refcount_set(&buf->refcount, 1);
return buf;
}
@@ -407,7 +408,7 @@ static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv,
unsigned long flags)
return NULL;
/* dmabuf keeps reference to vb2 buffer */
- atomic_inc(&buf->refcount);
+ refcount_inc(&buf->refcount);
return dbuf;
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 18/29] drivers, s390: convert urdev.ref_count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/s390/char/vmur.c | 8
drivers/s390/char/vmur.h | 4 +++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/s390/char/vmur.c b/drivers/s390/char/vmur.c
index 04aceb6..ced8151 100644
--- a/drivers/s390/char/vmur.c
+++ b/drivers/s390/char/vmur.c
@@ -110,7 +110,7 @@ static struct urdev *urdev_alloc(struct ccw_device *cdev)
mutex_init(&urd->io_mutex);
init_waitqueue_head(&urd->wait);
spin_lock_init(&urd->open_lock);
- atomic_set(&urd->ref_count, 1);
+ refcount_set(&urd->ref_count, 1);
urd->cdev = cdev;
get_device(&cdev->dev);
return urd;
@@ -126,7 +126,7 @@ static void urdev_free(struct urdev *urd)
static void urdev_get(struct urdev *urd)
{
- atomic_inc(&urd->ref_count);
+ refcount_inc(&urd->ref_count);
}
static struct urdev *urdev_get_from_cdev(struct ccw_device *cdev)
@@ -159,7 +159,7 @@ static struct urdev *urdev_get_from_devno(u16 devno)
static void urdev_put(struct urdev *urd)
{
- if (atomic_dec_and_test(&urd->ref_count))
+ if (refcount_dec_and_test(&urd->ref_count))
urdev_free(urd);
}
@@ -946,7 +946,7 @@ static int ur_set_offline_force(struct ccw_device *cdev,
int force)
rc = -EBUSY;
goto fail_urdev_put;
}
- if (!force && (atomic_read(&urd->ref_count) > 2)) {
+ if (!force && (refcount_read(&urd->ref_count) > 2)) {
/* There is still a user of urd (e.g. ur_open) */
TRACE("ur_set_offline: BUSY\n");
rc = -EBUSY;
diff --git a/drivers/s390/char/vmur.h b/drivers/s390/char/vmur.h
index fa320ad..35ea9d1 100644
--- a/drivers/s390/char/vmur.h
+++ b/drivers/s390/char/vmur.h
@@ -11,6 +11,8 @@
#ifndef _VMUR_H_
#define _VMUR_H_
+#include
+
#define DEV_CLASS_UR_I 0x20 /* diag210 unit record input device class */
#define DEV_CLASS_UR_O 0x10 /* diag210 unit record output device class */
/*
@@ -69,7 +71,7 @@ struct urdev {
size_t reclen; /* Record length for *write* CCWs */
int class; /* VM device class */
int io_request_rc; /* return code from I/O request */
- atomic_t ref_count; /* reference counter */
+ refcount_t ref_count; /* reference counter */
wait_queue_head_t wait; /* wait queue to serialize open */
int open_flag; /* "urdev is open" flag */
spinlock_t open_lock; /* serialize critical sections */
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 19/29] drivers, s390: convert lcs_reply.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/s390/net/lcs.c | 8 +++-
drivers/s390/net/lcs.h | 3 ++-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/s390/net/lcs.c b/drivers/s390/net/lcs.c
index 211b31d..18dc787 100644
--- a/drivers/s390/net/lcs.c
+++ b/drivers/s390/net/lcs.c
@@ -774,15 +774,13 @@ lcs_get_lancmd(struct lcs_card *card, int count)
static void
lcs_get_reply(struct lcs_reply *reply)
{
- WARN_ON(atomic_read(&reply->refcnt) <= 0);
- atomic_inc(&reply->refcnt);
+ refcount_inc(&reply->refcnt);
}
static void
lcs_put_reply(struct lcs_reply *reply)
{
-WARN_ON(atomic_read(&reply->refcnt) <= 0);
-if (atomic_dec_and_test(&reply->refcnt)) {
+if (refcount_dec_and_test(&reply->refcnt)) {
kfree(reply);
}
@@ -798,7 +796,7 @@ lcs_alloc_reply(struct lcs_cmd *cmd)
reply = kzalloc(sizeof(struct lcs_reply), GFP_ATOMIC);
if (!reply)
return NULL;
- atomic_set(&reply->refcnt,1);
+ refcount_set(&reply->refcnt,1);
reply->sequence_no = cmd->sequence_no;
reply->received = 0;
reply->rc = 0;
diff --git a/drivers/s390/net/lcs.h b/drivers/s390/net/lcs.h
index 150fcb4..3802f4f 100644
--- a/drivers/s390/net/lcs.h
+++ b/drivers/s390/net/lcs.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#define LCS_DBF_TEXT(level, name, text) \
@@ -270,7 +271,7 @@ struct lcs_buffer {
struct lcs_reply {
struct list_head list;
__u16 sequence_no;
- atomic_t refcnt;
+ refcount_t refcnt;
/* Callback for completion notification. */
void (*callback)(struct lcs_card *, struct lcs_cmd *);
wait_queue_head_t wait_q;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 20/29] drivers, s390: convert qeth_reply.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/s390/net/qeth_core.h | 3 ++-
drivers/s390/net/qeth_core_main.c | 8 +++-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/s390/net/qeth_core.h b/drivers/s390/net/qeth_core.h
index e7addea..e2c81d21 100644
--- a/drivers/s390/net/qeth_core.h
+++ b/drivers/s390/net/qeth_core.h
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -641,7 +642,7 @@ struct qeth_reply {
int rc;
void *param;
struct qeth_card *card;
- atomic_t refcnt;
+ refcount_t refcnt;
};
diff --git a/drivers/s390/net/qeth_core_main.c
b/drivers/s390/net/qeth_core_main.c
index 315d8a2..a2bf13f 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -555,7 +555,7 @@ static struct qeth_reply *qeth_alloc_reply(struct qeth_card
*card)
reply = kzalloc(sizeof(struct qeth_reply), GFP_ATOMIC);
if (reply) {
- atomic_set(&reply->refcnt, 1);
+ refcount_set(&reply->refcnt, 1);
atomic_set(&reply->received, 0);
reply->card = card;
}
@@ -564,14 +564,12 @@ static struct qeth_reply *qeth_alloc_reply(struct
qeth_card *card)
static void qeth_get_reply(struct qeth_reply *reply)
{
- WARN_ON(atomic_read(&reply->refcnt) <= 0);
- atomic_inc(&reply->refcnt);
+ refcount_inc(&reply->refcnt);
}
static void qeth_put_reply(struct qeth_reply *reply)
{
- WARN_ON(atomic_read(&reply->refcnt) <= 0);
- if (atomic_dec_and_test(&reply->refcnt))
+ if (refcount_dec_and_test(&reply->refcnt))
kfree(reply);
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/scsi/libiscsi.c| 8
drivers/scsi/qedi/qedi_iscsi.c | 2 +-
include/scsi/libiscsi.h| 3 ++-
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 834d121..7eb1d2c 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -516,13 +516,13 @@ static void iscsi_free_task(struct iscsi_task *task)
void __iscsi_get_task(struct iscsi_task *task)
{
- atomic_inc(&task->refcount);
+ refcount_inc(&task->refcount);
}
EXPORT_SYMBOL_GPL(__iscsi_get_task);
void __iscsi_put_task(struct iscsi_task *task)
{
- if (atomic_dec_and_test(&task->refcount))
+ if (refcount_dec_and_test(&task->refcount))
iscsi_free_task(task);
}
EXPORT_SYMBOL_GPL(__iscsi_put_task);
@@ -744,7 +744,7 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct
iscsi_hdr *hdr,
* released by the lld when it has transmitted the task for
* pdus we do not expect a response for.
*/
- atomic_set(&task->refcount, 1);
+ refcount_set(&task->refcount, 1);
task->conn = conn;
task->sc = NULL;
INIT_LIST_HEAD(&task->running);
@@ -1616,7 +1616,7 @@ static inline struct iscsi_task *iscsi_alloc_task(struct
iscsi_conn *conn,
sc->SCp.phase = conn->session->age;
sc->SCp.ptr = (char *) task;
- atomic_set(&task->refcount, 1);
+ refcount_set(&task->refcount, 1);
task->state = ISCSI_TASK_PENDING;
task->conn = conn;
task->sc = sc;
diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
index b9f79d3..3895bd5 100644
--- a/drivers/scsi/qedi/qedi_iscsi.c
+++ b/drivers/scsi/qedi/qedi_iscsi.c
@@ -1372,7 +1372,7 @@ static void qedi_cleanup_task(struct iscsi_task *task)
{
if (!task->sc || task->state == ISCSI_TASK_PENDING) {
QEDI_INFO(NULL, QEDI_LOG_IO, "Returning ref_cnt=%d\n",
- atomic_read(&task->refcount));
+ refcount_read(&task->refcount));
return;
}
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index b0e275d..24d74b5 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -139,7 +140,7 @@ struct iscsi_task {
/* state set/tested under session->lock */
int state;
- atomic_trefcount;
+ refcount_t refcount;
struct list_headrunning;/* running cmd list */
void*dd_data; /* driver/transport data */
};
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/scsi/libfc/fc_fcp.c | 6 +++---
include/scsi/libfc.h| 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c
index 0e67621..a808e8e 100644
--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -154,7 +154,7 @@ static struct fc_fcp_pkt *fc_fcp_pkt_alloc(struct fc_lport
*lport, gfp_t gfp)
memset(fsp, 0, sizeof(*fsp));
fsp->lp = lport;
fsp->xfer_ddp = FC_XID_UNKNOWN;
- atomic_set(&fsp->ref_cnt, 1);
+ refcount_set(&fsp->ref_cnt, 1);
init_timer(&fsp->timer);
fsp->timer.data = (unsigned long)fsp;
INIT_LIST_HEAD(&fsp->list);
@@ -175,7 +175,7 @@ static struct fc_fcp_pkt *fc_fcp_pkt_alloc(struct fc_lport
*lport, gfp_t gfp)
*/
static void fc_fcp_pkt_release(struct fc_fcp_pkt *fsp)
{
- if (atomic_dec_and_test(&fsp->ref_cnt)) {
+ if (refcount_dec_and_test(&fsp->ref_cnt)) {
struct fc_fcp_internal *si = fc_get_scsi_internal(fsp->lp);
mempool_free(fsp, si->scsi_pkt_pool);
@@ -188,7 +188,7 @@ static void fc_fcp_pkt_release(struct fc_fcp_pkt *fsp)
*/
static void fc_fcp_pkt_hold(struct fc_fcp_pkt *fsp)
{
- atomic_inc(&fsp->ref_cnt);
+ refcount_inc(&fsp->ref_cnt);
}
/**
diff --git a/include/scsi/libfc.h b/include/scsi/libfc.h
index da5033d..2109844 100644
--- a/include/scsi/libfc.h
+++ b/include/scsi/libfc.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -321,7 +322,7 @@ struct fc_seq_els_data {
*/
struct fc_fcp_pkt {
spinlock_tscsi_pkt_lock;
- atomic_t ref_cnt;
+ refcount_tref_cnt;
/* SCSI command and data transfer information */
u32 data_len;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 23/29] drivers: convert vme_user_vma_priv.refcnt from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/staging/vme/devices/vme_user.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_user.c
b/drivers/staging/vme/devices/vme_user.c
index 69e9a770..a3d4610 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -17,7 +17,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include
+#include
#include
#include
#include
@@ -118,7 +118,7 @@ static const int type[VME_DEVS] = { MASTER_MINOR,
MASTER_MINOR,
struct vme_user_vma_priv {
unsigned int minor;
- atomic_t refcnt;
+ refcount_t refcnt;
};
static ssize_t resource_to_user(int minor, char __user *buf, size_t count,
@@ -430,7 +430,7 @@ static void vme_user_vm_open(struct vm_area_struct *vma)
{
struct vme_user_vma_priv *vma_priv = vma->vm_private_data;
- atomic_inc(&vma_priv->refcnt);
+ refcount_inc(&vma_priv->refcnt);
}
static void vme_user_vm_close(struct vm_area_struct *vma)
@@ -438,7 +438,7 @@ static void vme_user_vm_close(struct vm_area_struct *vma)
struct vme_user_vma_priv *vma_priv = vma->vm_private_data;
unsigned int minor = vma_priv->minor;
- if (!atomic_dec_and_test(&vma_priv->refcnt))
+ if (!refcount_dec_and_test(&vma_priv->refcnt))
return;
mutex_lock(&image[minor].mutex);
@@ -473,7 +473,7 @@ static int vme_user_master_mmap(unsigned int minor, struct
vm_area_struct *vma)
}
vma_priv->minor = minor;
- atomic_set(&vma_priv->refcnt, 1);
+ refcount_set(&vma_priv->refcnt, 1);
vma->vm_ops = &vme_user_vm_ops;
vma->vm_private_data = vma_priv;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/target/target_core_iblock.c | 12 ++--
drivers/target/target_core_iblock.h | 3 ++-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/target/target_core_iblock.c
b/drivers/target/target_core_iblock.c
index d316ed5..bb069eb 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -279,7 +279,7 @@ static void iblock_complete_cmd(struct se_cmd *cmd)
struct iblock_req *ibr = cmd->priv;
u8 status;
- if (!atomic_dec_and_test(&ibr->pending))
+ if (!refcount_dec_and_test(&ibr->pending))
return;
if (atomic_read(&ibr->ib_bio_err_cnt))
@@ -487,7 +487,7 @@ iblock_execute_write_same(struct se_cmd *cmd)
bio_list_init(&list);
bio_list_add(&list, bio);
- atomic_set(&ibr->pending, 1);
+ refcount_set(&ibr->pending, 1);
while (sectors) {
while (bio_add_page(bio, sg_page(sg), sg->length, sg->offset)
@@ -498,7 +498,7 @@ iblock_execute_write_same(struct se_cmd *cmd)
if (!bio)
goto fail_put_bios;
- atomic_inc(&ibr->pending);
+ refcount_inc(&ibr->pending);
bio_list_add(&list, bio);
}
@@ -706,7 +706,7 @@ iblock_execute_rw(struct se_cmd *cmd, struct scatterlist
*sgl, u32 sgl_nents,
cmd->priv = ibr;
if (!sgl_nents) {
- atomic_set(&ibr->pending, 1);
+ refcount_set(&ibr->pending, 1);
iblock_complete_cmd(cmd);
return 0;
}
@@ -719,7 +719,7 @@ iblock_execute_rw(struct se_cmd *cmd, struct scatterlist
*sgl, u32 sgl_nents,
bio_list_init(&list);
bio_list_add(&list, bio);
- atomic_set(&ibr->pending, 2);
+ refcount_set(&ibr->pending, 2);
bio_cnt = 1;
for_each_sg(sgl, sg, sgl_nents, i) {
@@ -740,7 +740,7 @@ iblock_execute_rw(struct se_cmd *cmd, struct scatterlist
*sgl, u32 sgl_nents,
if (!bio)
goto fail_put_bios;
- atomic_inc(&ibr->pending);
+ refcount_inc(&ibr->pending);
bio_list_add(&list, bio);
bio_cnt++;
}
diff --git a/drivers/target/target_core_iblock.h
b/drivers/target/target_core_iblock.h
index 718d3fc..f2a5797 100644
--- a/drivers/target/target_core_iblock.h
+++ b/drivers/target/target_core_iblock.h
@@ -2,6 +2,7 @@
#define TARGET_CORE_IBLOCK_H
#include
+#include
#include
#define IBLOCK_VERSION "4.0"
@@ -10,7 +11,7 @@
#define IBLOCK_LBA_SHIFT 9
struct iblock_req {
- atomic_t pending;
+ refcount_t pending;
atomic_t ib_bio_err_cnt;
} cacheline_aligned;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 25/29] drivers, usb: convert ffs_data.ref from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/usb/gadget/function/f_fs.c | 8
drivers/usb/gadget/function/u_fs.h | 3 ++-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 87fccf6..3cdeb91 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1570,14 +1570,14 @@ static void ffs_data_get(struct ffs_data *ffs)
{
ENTER();
- atomic_inc(&ffs->ref);
+ refcount_inc(&ffs->ref);
}
static void ffs_data_opened(struct ffs_data *ffs)
{
ENTER();
- atomic_inc(&ffs->ref);
+ refcount_inc(&ffs->ref);
if (atomic_add_return(1, &ffs->opened) == 1 &&
ffs->state == FFS_DEACTIVATED) {
ffs->state = FFS_CLOSING;
@@ -1589,7 +1589,7 @@ static void ffs_data_put(struct ffs_data *ffs)
{
ENTER();
- if (unlikely(atomic_dec_and_test(&ffs->ref))) {
+ if (unlikely(refcount_dec_and_test(&ffs->ref))) {
pr_info("%s(): freeing\n", __func__);
ffs_data_clear(ffs);
BUG_ON(waitqueue_active(&ffs->ev.waitq) ||
@@ -1634,7 +1634,7 @@ static struct ffs_data *ffs_data_new(void)
ENTER();
- atomic_set(&ffs->ref, 1);
+ refcount_set(&ffs->ref, 1);
atomic_set(&ffs->opened, 0);
ffs->state = FFS_READ_DESCRIPTORS;
mutex_init(&ffs->mutex);
diff --git a/drivers/usb/gadget/function/u_fs.h
b/drivers/usb/gadget/function/u_fs.h
index 4b69694..abfca48 100644
--- a/drivers/usb/gadget/function/u_fs.h
+++ b/drivers/usb/gadget/function/u_fs.h
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#ifdef VERBOSE_DEBUG
#ifndef pr_vdebug
@@ -177,7 +178,7 @@ struct ffs_data {
struct completion ep0req_completion; /* P: mutex */
/* reference counter */
- atomic_tref;
+ refcount_t ref;
/* how many files are opened (EP0 and others) */
atomic_topened;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 27/29] drivers, usb: convert ep_data.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/usb/gadget/legacy/inode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index 81d76f3..d21a5f8 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -191,7 +191,7 @@ enum ep_state {
struct ep_data {
struct mutexlock;
enum ep_state state;
- atomic_tcount;
+ refcount_t count;
struct dev_data *dev;
/* must hold dev->lock before accessing ep or req */
struct usb_ep *ep;
@@ -206,12 +206,12 @@ struct ep_data {
static inline void get_ep (struct ep_data *data)
{
- atomic_inc (&data->count);
+ refcount_inc (&data->count);
}
static void put_ep (struct ep_data *data)
{
- if (likely (!atomic_dec_and_test (&data->count)))
+ if (likely (!refcount_dec_and_test (&data->count)))
return;
put_dev (data->dev);
/* needs no more cleanup */
@@ -1562,7 +1562,7 @@ static int activate_ep_files (struct dev_data *dev)
init_waitqueue_head (&data->wait);
strncpy (data->name, ep->name, sizeof (data->name) - 1);
- atomic_set (&data->count, 1);
+ refcount_set (&data->count, 1);
data->dev = dev;
get_dev (dev);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/xen/gntdev.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 2ef2b61..b183cb2 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -85,7 +86,7 @@ struct grant_map {
int index;
int count;
int flags;
- atomic_t users;
+ refcount_t users;
struct unmap_notify notify;
struct ioctl_gntdev_grant_ref *grants;
struct gnttab_map_grant_ref *map_ops;
@@ -165,7 +166,7 @@ static struct grant_map *gntdev_alloc_map(struct
gntdev_priv *priv, int count)
add->index = 0;
add->count = count;
- atomic_set(&add->users, 1);
+ refcount_set(&add->users, 1);
return add;
@@ -211,7 +212,7 @@ static void gntdev_put_map(struct gntdev_priv *priv, struct
grant_map *map)
if (!map)
return;
- if (!atomic_dec_and_test(&map->users))
+ if (!refcount_dec_and_test(&map->users))
return;
atomic_sub(map->count, &pages_mapped);
@@ -399,7 +400,7 @@ static void gntdev_vma_open(struct vm_area_struct *vma)
struct grant_map *map = vma->vm_private_data;
pr_debug("gntdev_vma_open %p\n", vma);
- atomic_inc(&map->users);
+ refcount_inc(&map->users);
}
static void gntdev_vma_close(struct vm_area_struct *vma)
@@ -1003,7 +1004,7 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
goto unlock_out;
}
- atomic_inc(&map->users);
+ refcount_inc(&map->users);
vma->vm_ops = &gntdev_vmops;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 28/29] drivers: convert sbd_duart.map_guard from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/tty/serial/sb1250-duart.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/sb1250-duart.c
b/drivers/tty/serial/sb1250-duart.c
index 771f361..041625c 100644
--- a/drivers/tty/serial/sb1250-duart.c
+++ b/drivers/tty/serial/sb1250-duart.c
@@ -41,7 +41,7 @@
#include
#include
-#include
+#include
#include
#include
@@ -103,7 +103,7 @@ struct sbd_port {
struct sbd_duart {
struct sbd_port sport[2];
unsigned long mapctrl;
- atomic_tmap_guard;
+ refcount_t map_guard;
};
#define to_sport(uport) container_of(uport, struct sbd_port, port)
@@ -654,15 +654,13 @@ static void sbd_release_port(struct uart_port *uport)
{
struct sbd_port *sport = to_sport(uport);
struct sbd_duart *duart = sport->duart;
- int map_guard;
iounmap(sport->memctrl);
sport->memctrl = NULL;
iounmap(uport->membase);
uport->membase = NULL;
- map_guard = atomic_add_return(-1, &duart->map_guard);
- if (!map_guard)
+ if(refcount_dec_and_test(&duart->map_guard))
release_mem_region(duart->mapctrl, DUART_CHANREG_SPACING);
release_mem_region(uport->mapbase, DUART_CHANREG_SPACING);
}
@@ -698,7 +696,6 @@ static int sbd_request_port(struct uart_port *uport)
{
const char *err = KERN_ERR "sbd: Unable to reserve MMIO resource\n";
struct sbd_duart *duart = to_sport(uport)->duart;
- int map_guard;
int ret = 0;
if (!request_mem_region(uport->mapbase, DUART_CHANREG_SPACING,
@@ -706,11 +703,11 @@ static int sbd_request_port(struct uart_port *uport)
printk(err);
return -EBUSY;
}
- map_guard = atomic_add_return(1, &duart->map_guard);
- if (map_guard == 1) {
+ refcount_inc(&duart->map_guard);
+ if (refcount_read(&duart->map_guard) == 1) {
if (!request_mem_region(duart->mapctrl, DUART_CHANREG_SPACING,
"sb1250-duart")) {
- atomic_add(-1, &duart->map_guard);
+ refcount_dec(&duart->map_guard);
printk(err);
ret = -EBUSY;
}
@@ -718,8 +715,7 @@ static int sbd_request_port(struct uart_port *uport)
if (!ret) {
ret = sbd_map_port(uport);
if (ret) {
- map_guard = atomic_add_return(-1, &duart->map_guard);
- if (!map_guard)
+ if (refcount_dec_and_test(&duart->map_guard))
release_mem_region(duart->mapctrl,
DUART_CHANREG_SPACING);
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 26/29] drivers, usb: convert dev_data.count from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
drivers/usb/gadget/legacy/inode.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index 79a2d8f..81d76f3 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -114,7 +115,7 @@ enum ep0_state {
struct dev_data {
spinlock_t lock;
- atomic_tcount;
+ refcount_t count;
enum ep0_state state; /* P: lock */
struct usb_gadgetfs_event event [N_EVENT];
unsignedev_next;
@@ -150,12 +151,12 @@ struct dev_data {
static inline void get_dev (struct dev_data *data)
{
- atomic_inc (&data->count);
+ refcount_inc (&data->count);
}
static void put_dev (struct dev_data *data)
{
- if (likely (!atomic_dec_and_test (&data->count)))
+ if (likely (!refcount_dec_and_test (&data->count)))
return;
/* needs no more cleanup */
BUG_ON (waitqueue_active (&data->wait));
@@ -170,7 +171,7 @@ static struct dev_data *dev_new (void)
if (!dev)
return NULL;
dev->state = STATE_DEV_DISABLED;
- atomic_set (&dev->count, 1);
+ refcount_set (&dev->count, 1);
spin_lock_init (&dev->lock);
INIT_LIST_HEAD (&dev->epfiles);
init_waitqueue_head (&dev->wait);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
Hi Daniel, On Monday 06 Mar 2017 11:38:20 Daniel Vetter wrote: > On Fri, Mar 03, 2017 at 06:45:40PM +0200, Laurent Pinchart wrote: > > - I haven't seen any proposal how a heap-based solution could be used in a > > generic distribution. This needs to be figured out before committing to > > any API/ABI. > > Two replies from my side: > > - Just because a patch doesn't solve world hunger isn't really a good > reason to reject it. As long as it goes in the right direction, sure :-) The points I mentioned were to be interpreted that way, I want to make sure we're not going in a dead-end (or worse, driving full speed into a wall). > - Heap doesn't mean its not resizeable (but I'm not sure that's really > your concern). Not really, no. Heap is another word to mean pool here. It might not be the best term in this context as it has a precise meaning in the context of memory allocation, but that's a detail. > - Imo ION is very much part of the picture here to solve this for real. We > need to bits: > > * Be able to allocate memory from specific pools, not going through a > specific driver. ION gives us that interface. This is e.g. also needed > for "special" memory, like SMA tries to expose. > > * Some way to figure out how&where to allocate the buffer object. This > is purely a userspace problem, and this is the part the unix memory > allocator tries to solve. There's no plans in there for big kernel > changes, instead userspace does a dance to reconcile all the > constraints, and one of the constraints might be "you have to allocate > this from this special ION heap". The only thing the kernel needs to > expose is which devices use which ION heaps (we kinda do that > already), and maybe some hints of how they can be generalized (but I > guess stuff like "minimal pagesize of x KB" is also fulfilled by any > CMA heap is knowledge userspace needs). The constraint solver could live in userspace, I'm open to a solution that would go in that direction, but it will require help from the kernel to fetch the constraints from the devices that need to be involved in buffer sharing. Given a userspace constraint resolver, the interface with the kernel allocator will likely be based on pools. I'm not opposed to that, as long as pool are identified by opaque handles. I don't want userspace to know about the meaning of any particular ION heap. Application must not attempt to "allocate from CMA" for instance, that would lock us to a crazy API that will grow completely out of hands as vendors will start adding all kind of custom heaps, and applications will have to follow (or will be patched out-of-tree by vendors). > Again I think waiting for this to be fully implemented before we merge any > part is going to just kill any upstreaming efforts. ION in itself, without > the full buffer negotiation dance seems clearly useful (also for stuff > like SMA), and having it merged will help with moving the buffer > allocation dance forward. Again I'm not opposed to a kernel allocator based on pools/heaps, as long as - pools/heaps stay internal to the kernel and are not directly exposed to userspace - a reasonable way to size the different kinds of pools in a generic distribution kernel can be found -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/5] staging: lustre: osc_page.c: Use list_for_each_entry_safe
> Doubly linked lists which are iterated using list_empty
> and list_entry macros have been replaced with list_for_each_entry_safe
> macro.
> This makes the iteration simpler and more readable.
>
> This patch replaces the while loop containing list_empty and list_entry
> with list_for_each_entry_safe.
>
> This was done with Coccinelle.
>
> @@
> expression E1;
> identifier I1, I2;
> type T;
> iterator name list_for_each_entry_safe;
> @@
>
> T *I1;
> + T *tmp;
> ...
> - while (list_empty(&E1) == 0)
> + list_for_each_entry_safe (I1, tmp, &E1, I2)
> {
> ...when != T *I1;
> - I1 = list_entry(E1.next, T, I2);
> ...
> }
>
> Signed-off-by: simran singhal
NAK!!
This change was reverted in commit
cd15dd6ef4ea11df87f717b8b1b83aaa738ec8af
Doing these while (list_empty(..)) to list_for_entry...
are not simple changes and have broken things in lustre
before. Unless you really understand the state machine of
the lustre code I don't recommend these kinds of change
for lustre.
> ---
> drivers/staging/lustre/lustre/osc/osc_page.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/osc/osc_page.c
> b/drivers/staging/lustre/lustre/osc/osc_page.c
> index ed8a0dc..e8b974f 100644
> --- a/drivers/staging/lustre/lustre/osc/osc_page.c
> +++ b/drivers/staging/lustre/lustre/osc/osc_page.c
> @@ -542,6 +542,7 @@ long osc_lru_shrink(const struct lu_env *env, struct
> client_obd *cli,
> struct cl_object *clobj = NULL;
> struct cl_page **pvec;
> struct osc_page *opg;
> + struct osc_page *tmp;
> int maxscan = 0;
> long count = 0;
> int index = 0;
> @@ -572,7 +573,7 @@ long osc_lru_shrink(const struct lu_env *env, struct
> client_obd *cli,
> if (force)
> cli->cl_lru_reclaim++;
> maxscan = min(target << 1, atomic_long_read(&cli->cl_lru_in_list));
> - while (!list_empty(&cli->cl_lru_list)) {
> + list_for_each_entry_safe(opg, tmp, &cli->cl_lru_list, ops_lru) {
> struct cl_page *page;
> bool will_free = false;
>
> @@ -582,8 +583,6 @@ long osc_lru_shrink(const struct lu_env *env, struct
> client_obd *cli,
> if (--maxscan < 0)
> break;
>
> - opg = list_entry(cli->cl_lru_list.next, struct osc_page,
> - ops_lru);
> page = opg->ops_cl.cpl_page;
> if (lru_page_busy(cli, page)) {
> list_move_tail(&opg->ops_lru, &cli->cl_lru_list);
> @@ -1043,6 +1042,7 @@ unsigned long osc_cache_shrink_scan(struct shrinker *sk,
> {
> struct client_obd *stop_anchor = NULL;
> struct client_obd *cli;
> + struct client_obd *tmp;
> struct lu_env *env;
> long shrank = 0;
> u16 refcheck;
> @@ -1059,10 +1059,7 @@ unsigned long osc_cache_shrink_scan(struct shrinker
> *sk,
> return SHRINK_STOP;
>
> spin_lock(&osc_shrink_lock);
> - while (!list_empty(&osc_shrink_list)) {
> - cli = list_entry(osc_shrink_list.next, struct client_obd,
> - cl_shrink_list);
> -
> + list_for_each_entry_safe(cli, tmp, &osc_shrink_list, cl_shrink_list) {
> if (!stop_anchor)
> stop_anchor = cli;
> else if (cli == stop_anchor)
> --
> 2.7.4
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH V4] staging: vchiq_arm: Add compatibility wrappers for ioctls
On Wed, Mar 01, 2017 at 07:41:46PM -0800, Michael Zoran wrote:
> This patch adds compatibility wrappers for the ioctls
> exposed by vchiq/vc04_services. The compat ioctls are
> completely implemented on top of the native ioctls. No
> existing lines are modified.
>
> While the ideal approach would be to cleanup the existing
> code, this path is simplier and easier to review. While
> it does have a small runtime performance penality vs
> seperating the existing code into wrapper+worker functions,
> the penality is small since only the metadata is copied
> back onto the 32 bit user mode stack.
>
> The on top of approach is the approach used by several
> existing performance critical subsystems of Linux such
> as the DRM 3D graphics subsystem.
>
> Testing:
>
> 1. A 32 bit chroot was created on a RPI 3 and vchiq_test
> was built for armhf. The usual tests were run such as
> vchiq_test -f 10 and vchiq_test -p.
>
> 2. This patch was applied to the shipping version of
> the Linux kernel used for the RPI and that kernel was
> built for arm64. That kernel was used to boot Raspbian.
> Many of the builtin features are now functional such
> as the "hello_pi" examples, and minecraft_pi.
>
> Changes:
> V1 - Complete rewrite of the ioctl code.
> V2 - Rewrite of only ioctls that change
> between 32 bit and 64 bit.
> V3 - Minor changes.
> V4(This Version) - Abandon cleaning up the
>exising code and completely write the
>wrappers on top of the native ioctls.
>No existing lines are changed.
>
> Signed-off-by: Michael Zoran
> ---
> .../vc04_services/interface/vchiq_arm/vchiq_arm.c | 446
> +
> 1 file changed, 446 insertions(+)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> index 19bd4ac6e855..90dfa79089d3 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "vchiq_core.h"
> @@ -1227,6 +1228,448 @@ vchiq_ioctl(struct file *file, unsigned int cmd,
> unsigned long arg)
> return ret;
> }
>
> +#if defined(CONFIG_COMPAT)
> +
> +struct vchiq_service_params32 {
> + int fourcc;
> + compat_uptr_t callback;
> + compat_uptr_t userdata;
> + short version; /* Increment for non-trivial changes */
> + short version_min; /* Update for incompatible changes */
> +};
> +
> +struct vchiq_create_service32 {
> + struct vchiq_service_params32 params;
> + int is_open;
> + int is_vchi;
> + unsigned int handle; /* OUT */
> +};
> +
> +#define VCHIQ_IOC_CREATE_SERVICE32 \
> + _IOWR(VCHIQ_IOC_MAGIC, 2, struct vchiq_create_service32)
> +
> +static long
> +vchiq_compat_ioctl_create_service(
> + struct file *file,
> + unsigned int cmd,
> + unsigned long arg)
> +{
> + VCHIQ_CREATE_SERVICE_T __user *args;
> + struct vchiq_create_service32 __user *ptrargs32 =
> + (struct vchiq_create_service32 __user *)arg;
> + struct vchiq_create_service32 args32;
> + long ret;
> +
> + args = compat_alloc_user_space(sizeof(*args));
> + if (!args)
> + return -EFAULT;
> +
> + if (copy_from_user(&args32,
> +(struct vchiq_create_service32 __user *)arg,
> +sizeof(args32)))
> + return -EFAULT;
> +
> + if (put_user(args32.params.fourcc, &args->params.fourcc) ||
> + put_user(compat_ptr(args32.params.callback),
> + &args->params.callback) ||
> + put_user(compat_ptr(args32.params.userdata),
> + &args->params.userdata) ||
> + put_user(args32.params.version, &args->params.version) ||
> + put_user(args32.params.version_min,
> + &args->params.version_min) ||
> + put_user(args32.is_open, &args->is_open) ||
> + put_user(args32.is_vchi, &args->is_vchi) ||
> + put_user(args32.handle, &args->handle))
> + return -EFAULT;
> +
> + ret = vchiq_ioctl(file, VCHIQ_IOC_CREATE_SERVICE, (unsigned long)args);
> +
> + if (ret < 0)
> + return ret;
> +
> + if (get_user(args32.handle, &args->handle))
> + return -EFAULT;
> +
> + if (copy_to_user(&ptrargs32->handle,
> + &args32.handle,
> + sizeof(args32.handle)))
> + return -EFAULT;
> +
> + return ret;
return 0;
> +}
> +
> +struct vchiq_element32 {
> + compat_uptr_t data;
> + unsigned int size;
> +};
> +
> +struct vchiq_queue_message32 {
> + unsigned int handle;
> + unsigned int count;
> + compat_uptr_t elements;
> +};
> +
> +#define VCHIQ_IOC_QUEUE_MESSAGE32 \
> + _IOW(VCHIQ_IOC_MAGIC, 4, struct vchiq_queue_message32)
> +
> +static long
> +vchiq_comp
Re: [PATCH] Staging: media: platform: bcm2835 - Style fix
On Sun, Mar 05, 2017 at 10:43:19AM +1300, Derek Robson wrote: > On Sat, Mar 04, 2017 at 02:57:22PM +0300, Dan Carpenter wrote: > > Copy a patch prefix that everyone else has been using: > > > > git log --oneline drivers/staging/media/platform/bcm2835/ > > > > The subject is too vague as well. > > Is this what you are looking for? > > [patch] Staging: bcm2835: fixed style of block comments > > And should I just re-send as a V2 with new subject? Yes. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
On 03/06/2017 03:21 PM, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. The subject is wrong, should be something like "scsi: libfc convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390. Other than that Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly
On Mon, Mar 06, 2017 at 03:43:53PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote: > > On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote: > > > On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > > >> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > > >>> When CMA was first introduced, its primary use was for DMA allocation > > >>> and the only way to get CMA memory was to call dma_alloc_coherent. This > > >>> put Ion in an awkward position since there was no device structure > > >>> readily available and setting one up messed up the coherency model. > > >>> These days, CMA can be allocated directly from the APIs. Switch to > > >>> using this model to avoid needing a dummy device. This also avoids > > >>> awkward caching questions. > > >> > > >> If the DMA mapping API isn't suitable for today's requirements anymore, > > >> I believe that's what needs to be fixed, instead of working around the > > >> problem by introducing another use-case-specific API. > > > > > > I don't think this is a usecase specific API. CMA has been decoupled from > > > DMA already because it's used in other places. The trying to go through > > > DMA was just another layer of abstraction, especially since there isn't > > > a device available for allocation. > > > > Also, we've had separation of allocation and dma-mapping since forever, > > that's how it works almost everywhere. Not exactly sure why/how arm-soc > > ecosystem ended up focused so much on dma_alloc_coherent. > > I believe because that was the easy way to specify memory constraints. The > API > receives a device pointer and will allocate memory suitable for DMA for that > device. The fact that it maps it to the device is a side-effect in my opinion. > > > I think separating allocation from dma mapping/coherency is perfectly > > fine, and the way to go. > > Especially given that in many cases we'll want to share buffers between > multiple devices, so we'll need to map them multiple times. > > My point still stands though, if we want to move towards a model where > allocation and mapping are decoupled, we need an allocation function that > takes constraints (possibly implemented with two layers, a constraint > resolution layer on top of a pool/heap/type/foo-based allocator), and a > mapping API. IOMMU handling being integrated in the DMA mapping API we're > currently stuck with it, which might call for brushing up that API. Hm, maybe I wasn't clear, but that's exactly what I assume will happen: The constraint resolver is the unix device memory allocation thing, which happens entirely in userspace. There's a lot more than just "where to allocate" to negotiate, e.g. pixel format, stride/size limits/requirements, tiling formats. A lot of it the kernel doesn't even know. Allocation then needs to happen through the kernel ofc, but that doesn't mean we need to have all the constraint resolving in the kernel. As long as the kernel exposes the device /dev node -> ion heap stuff, userspace can figure this out. Or an alternative way would be to have a cascade of ion heaps to keep things a notch more opaque. Either way, no actaul constraint resolving in the kernel itself, and except for a bunch more stuff in sysfs maybe, also no other uapi changes. Once we have a place to allocate stuff which isn't the device driver at least, aka ION. And then once allocated you use the dma apis to instantiate the iommus mappings. Anyway, at least from my understanding I think there's 0 risk with merging ION wrt the constraint resolving side (at least as discussed around XDC last year), and for setups that need cma, it might finally enable to get things moving forward. Or do I miss something big here? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH V4] staging: vchiq_arm: Add compatibility wrappers for ioctls
On Mon, 2017-03-06 at 14:01 +0100, Greg KH wrote: > On Sat, Mar 04, 2017 at 06:57:50AM -0800, Michael Zoran wrote: > > On Sat, 2017-03-04 at 14:58 +0300, Dan Carpenter wrote: > > > On Wed, Mar 01, 2017 at 07:41:46PM -0800, Michael Zoran wrote: > > > > Changes: > > > > V1 - Complete rewrite of the ioctl code. > > > > V2 - Rewrite of only ioctls that change > > > > between 32 bit and 64 bit. > > > > V3 - Minor changes. > > > > V4(This Version) - Abandon cleaning up the > > > > exising code and completely write the > > > > wrappers on top of the native ioctls. > > > > No existing lines are changed. > > > > > > I think I objected to earlier versions but this approach looks > > > nice. > > > > > > regards, > > > dan carpenter > > > > > > > Cool, does this mean I get an ACK? > > > > It really would be good to get this in since it's one of the last > > major > > missing pieces to get Raspbian to work with a 64 bit kernel. > > I'll be glad to take this if you respin it with the fixes that Eric > asked for :) > > thanks, > > greg k-h Hi Greg, I have no problem doing a v5, just that Eric's fixes for await completion will not work at all. Only handling the case of 1 passed in would completely break vchiq_test which is the main test application and would break all of 32 bit user mode which would defeat the point of the wrappers. If Eric or anybody else has another way to fix await completion that will actually work, I'm more then willing to do it that way. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On Mon, Mar 06, 2017 at 05:02:05PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Monday 06 Mar 2017 11:38:20 Daniel Vetter wrote: > > On Fri, Mar 03, 2017 at 06:45:40PM +0200, Laurent Pinchart wrote: > > > - I haven't seen any proposal how a heap-based solution could be used in a > > > generic distribution. This needs to be figured out before committing to > > > any API/ABI. > > > > Two replies from my side: > > > > - Just because a patch doesn't solve world hunger isn't really a good > > reason to reject it. > > As long as it goes in the right direction, sure :-) The points I mentioned > were to be interpreted that way, I want to make sure we're not going in a > dead-end (or worse, driving full speed into a wall). > > > - Heap doesn't mean its not resizeable (but I'm not sure that's really > > your concern). > > Not really, no. Heap is another word to mean pool here. It might not be the > best term in this context as it has a precise meaning in the context of > memory > allocation, but that's a detail. > > > - Imo ION is very much part of the picture here to solve this for real. We > > need to bits: > > > > * Be able to allocate memory from specific pools, not going through a > > specific driver. ION gives us that interface. This is e.g. also needed > > for "special" memory, like SMA tries to expose. > > > > * Some way to figure out how&where to allocate the buffer object. This > > is purely a userspace problem, and this is the part the unix memory > > allocator tries to solve. There's no plans in there for big kernel > > changes, instead userspace does a dance to reconcile all the > > constraints, and one of the constraints might be "you have to allocate > > this from this special ION heap". The only thing the kernel needs to > > expose is which devices use which ION heaps (we kinda do that > > already), and maybe some hints of how they can be generalized (but I > > guess stuff like "minimal pagesize of x KB" is also fulfilled by any > > CMA heap is knowledge userspace needs). > > The constraint solver could live in userspace, I'm open to a solution that > would go in that direction, but it will require help from the kernel to fetch > the constraints from the devices that need to be involved in buffer sharing. > > Given a userspace constraint resolver, the interface with the kernel > allocator > will likely be based on pools. I'm not opposed to that, as long as pool are > identified by opaque handles. I don't want userspace to know about the > meaning > of any particular ION heap. Application must not attempt to "allocate from > CMA" for instance, that would lock us to a crazy API that will grow > completely > out of hands as vendors will start adding all kind of custom heaps, and > applications will have to follow (or will be patched out-of-tree by vendors). > > > Again I think waiting for this to be fully implemented before we merge any > > part is going to just kill any upstreaming efforts. ION in itself, without > > the full buffer negotiation dance seems clearly useful (also for stuff > > like SMA), and having it merged will help with moving the buffer > > allocation dance forward. > > Again I'm not opposed to a kernel allocator based on pools/heaps, as long as > > - pools/heaps stay internal to the kernel and are not directly exposed to > userspace Agreed (and I think ION doesn't have fixed pools afaik, just kinda conventions, at least after Laura's patches). But on a fixed board with a fixed DT (for the cma regions) and fixed .config (for the generic heaps) you can hardcode your heaps. You'll make your code non-portable, but hey that's not our problem imo. E.g. board-specific code can also hard-code how to wire connectors and which one is which in kms (and I've seen this). I don't think the possibility of abusing the uabi should be a good reason to prevent it from merging. Anything that provides something with indirect connections can be abused by hardcoding the names or the indizes. We do have a TODO entry that talks about exposing the device -> cma heap link in sysfs or somewhere. I'm not versed enough to know whether Laura's patches fixed that, this here mostly seems to tackle the fundamentals of the dma api abuse first. > - a reasonable way to size the different kinds of pools in a generic > distribution kernel can be found So for the CMA heaps, you can't resize them at runtime, for obvious reasons. For boot-time you can adjust them through DT, and I thought everyone agreed that for different use-cases you might need to adjust your reserved regions. For all other heaps, they just use the normal allocator functions (e.g. alloc_pages). There's not limit on those except OOM, so nothing to adjust really. I guess I'm still not entirely clear on your "memory pool" concern ... If it's just the word, we have lots of auto-resizing heaps/pools all around. And if it's just sizing, I think that's already solve
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote: > On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote: > > > No one gave a thing about android in upstream, so Greg KH just dumped it > > all into staging/android/. We've discussed ION a bunch of times, recorded > > anything we'd like to fix in staging/android/TODO, and Laura's patch > > series here addresses a big chunk of that. > > > This is pretty much the same approach we (gpu folks) used to de-stage the > > syncpt stuff. > > Well, there's also the fact that quite a few people have issues with the > design (like Laurent). It seems like a lot of them have either got more > comfortable with it over time, or at least not managed to come up with > any better ideas in the meantime. See the TODO, it has everything a really big group (look at the patch for the full Cc: list) figured needs to be improved at LPC 2015. We don't just merge stuff because merging stuff is fun :-) Laurent was even in that group ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH V4] staging: vchiq_arm: Add compatibility wrappers for ioctls
On Mon, 2017-03-06 at 18:22 +0300, Dan Carpenter wrote:
> > +
> > +struct vchiq_completion_data32 {
> > + VCHIQ_REASON_T reason;
> > + compat_uptr_t header;
> > + compat_uptr_t service_userdata;
> > + compat_uptr_t bulk_userdata;
> > +};
> > +
> > +struct vchiq_await_completion32 {
> > + unsigned int count;
> > + compat_uptr_t buf;
> > + unsigned int msgbufsize;
> > + unsigned int msgbufcount; /* IN/OUT */
> > + compat_uptr_t msgbufs;
> > +};
> > +
> > +#define VCHIQ_IOC_AWAIT_COMPLETION32 \
> > + _IOWR(VCHIQ_IOC_MAGIC, 7, struct vchiq_await_completion32)
> > +
> > +static long
> > +vchiq_compat_ioctl_await_completion(struct file *file,
> > + unsigned int cmd,
> > + unsigned long arg)
> > +{
> > + VCHIQ_AWAIT_COMPLETION_T *args;
> > + VCHIQ_COMPLETION_DATA_T *completion;
> > + VCHIQ_COMPLETION_DATA_T completiontemp;
> > + struct vchiq_await_completion32 args32;
> > + struct vchiq_completion_data32 completion32;
> > + unsigned int *msgbufcount32;
> > + compat_uptr_t msgbuf32;
> > + void *msgbuf;
> > + void **msgbufptr;
> > + long ret;
> > +
> > + args = compat_alloc_user_space(sizeof(*args) +
> > + sizeof(*completion) +
> > + sizeof(*msgbufptr));
> > + if (!args)
> > + return -EFAULT;
> > +
> > + completion = (VCHIQ_COMPLETION_DATA_T *)(args + 1);
> > + msgbufptr = (void __user **)(completion + 1);
> > +
> > + if (copy_from_user(&args32,
> > + (struct vchiq_completion_data32 *)arg,
> > + sizeof(args32)))
> > + return -EFAULT;
> > +
> > + if (put_user(args32.count, &args->count) ||
> > + put_user(compat_ptr(args32.buf), &args->buf) ||
> > + put_user(args32.msgbufsize, &args->msgbufsize) ||
> > + put_user(args32.msgbufcount, &args->msgbufcount) ||
> > + put_user(compat_ptr(args32.msgbufs), &args->msgbufs))
> > + return -EFAULT;
> > +
> > + if (!args32.count || !args32.buf || !args32.msgbufcount)
> > + return vchiq_ioctl(file,
> > + VCHIQ_IOC_AWAIT_COMPLETION,
> > + (unsigned long)args);
> > +
> > + if (copy_from_user(&msgbuf32,
> > + compat_ptr(args32.msgbufs) +
> > + (sizeof(compat_uptr_t) *
> > + (args32.msgbufcount - 1)),
> > + sizeof(msgbuf32)))
> > + return -EFAULT;
> > +
> > + msgbuf = compat_ptr(msgbuf32);
> > +
> > + if (copy_to_user(msgbufptr,
> > + &msgbuf,
> > + sizeof(msgbuf)))
> > + return -EFAULT;
> > +
> > + if (copy_to_user(&args->msgbufs,
> > + &msgbufptr,
> > + sizeof(msgbufptr)))
> > + return -EFAULT;
> > +
> > + if (put_user(1U, &args->count) ||
> > + put_user(completion, &args->buf) ||
> > + put_user(1U, &args->msgbufcount))
> > + return -EFAULT;
> > +
> > + ret = vchiq_ioctl(file,
> > + VCHIQ_IOC_AWAIT_COMPLETION,
> > + (unsigned long)args);
> > +
> > + if (ret <= 0)
>
> Really?
>
Believe it or not, this code actually does work. It's the original
code that's convoluted.
By forcing 1 for args->count and args->msgbufcount, it avoids all the
broken code paths in the original code.
Here is a brief summary of what the orignal code returns:
0: No messages where available.
>0: Number of messages that were availably but never more then args-
>count.
<0: An error occured, but only if only 1 message was available.
Otherwise return the count of available messages.
> > + return ret;
> > +
> > + if (copy_from_user(&completiontemp, completion,
> > sizeof(*completion)))
> > + return -EFAULT;
> > +
> > + completion32.reason = completiontemp.reason;
> > + completion32.header =
> > ptr_to_compat(completiontemp.header);
> > + completion32.service_userdata =
> > + ptr_to_compat(completiontemp.service_userdata);
> > + completion32.bulk_userdata =
> > + ptr_to_compat(completiontemp.bulk_userdata);
> > +
> > + if (copy_to_user(compat_ptr(args32.buf),
> > + &completion32,
> > + sizeof(completion32)))
> > + return -EFAULT;
> > +
> > + args32.msgbufcount--;
> > +
> > + msgbufcount32 =
> > + &((struct vchiq_await_completion32 __user *)arg)-
> > >msgbufcount;
> > +
> > + if (copy_to_user(msgbufcount32,
> > + &args32.msgbufcount,
> > + sizeof(args32.msgbufcount)))
> > + return -EFAULT;
> > +
> > + return ret;
>
> return 0;
>
The other fixes are very easy to make and I have no problem changes
those.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.or
Re: [RESEND PATCH V4] staging: vchiq_arm: Add compatibility wrappers for ioctls
Am 06.03.2017 um 16:57 schrieb Michael Zoran: > On Mon, 2017-03-06 at 14:01 +0100, Greg KH wrote: >> On Sat, Mar 04, 2017 at 06:57:50AM -0800, Michael Zoran wrote: >>> On Sat, 2017-03-04 at 14:58 +0300, Dan Carpenter wrote: On Wed, Mar 01, 2017 at 07:41:46PM -0800, Michael Zoran wrote: > Changes: > V1 - Complete rewrite of the ioctl code. > V2 - Rewrite of only ioctls that change > between 32 bit and 64 bit. > V3 - Minor changes. > V4(This Version) - Abandon cleaning up the >exising code and completely write the >wrappers on top of the native ioctls. >No existing lines are changed. I think I objected to earlier versions but this approach looks nice. regards, dan carpenter >>> Cool, does this mean I get an ACK? >>> >>> It really would be good to get this in since it's one of the last >>> major >>> missing pieces to get Raspbian to work with a 64 bit kernel. >> I'll be glad to take this if you respin it with the fixes that Eric >> asked for :) >> >> thanks, >> >> greg k-h > Hi Greg, > > I have no problem doing a v5, just that Eric's fixes for await > completion will not work at all. > > Only handling the case of 1 passed in would completely break vchiq_test > which is the main test application and would break all of 32 bit user > mode which would defeat the point of the wrappers. If we couldn't find a solution, it would be nice to have an explaining comment at this place. > > If Eric or anybody else has another way to fix await completion that > will actually work, I'm more then willing to do it that way. Regarding to my comments it's okay to keep the memdump and introduce the Kconfig parameter for all dumps later. Stefan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH V4] staging: vchiq_arm: Add compatibility wrappers for ioctls
On Mon, 2017-03-06 at 17:11 +0100, Stefan Wahren wrote: > Am 06.03.2017 um 16:57 schrieb Michael Zoran: > > On Mon, 2017-03-06 at 14:01 +0100, Greg KH wrote: > > > On Sat, Mar 04, 2017 at 06:57:50AM -0800, Michael Zoran wrote: > > > > On Sat, 2017-03-04 at 14:58 +0300, Dan Carpenter wrote: > > > > > On Wed, Mar 01, 2017 at 07:41:46PM -0800, Michael Zoran > > > > > wrote: > > > > > > Changes: > > > > > > V1 - Complete rewrite of the ioctl code. > > > > > > V2 - Rewrite of only ioctls that change > > > > > > between 32 bit and 64 bit. > > > > > > V3 - Minor changes. > > > > > > V4(This Version) - Abandon cleaning up the > > > > > > exising code and completely write the > > > > > > wrappers on top of the native ioctls. > > > > > > No existing lines are changed. > > > > > > > > > > I think I objected to earlier versions but this approach > > > > > looks > > > > > nice. > > > > > > > > > > regards, > > > > > dan carpenter > > > > > > > > > > > > > Cool, does this mean I get an ACK? > > > > > > > > It really would be good to get this in since it's one of the > > > > last > > > > major > > > > missing pieces to get Raspbian to work with a 64 bit kernel. > > > > > > I'll be glad to take this if you respin it with the fixes that > > > Eric > > > asked for :) > > > > > > thanks, > > > > > > greg k-h > > > > Hi Greg, > > > > I have no problem doing a v5, just that Eric's fixes for await > > completion will not work at all. > > > > Only handling the case of 1 passed in would completely break > > vchiq_test > > which is the main test application and would break all of 32 bit > > user > > mode which would defeat the point of the wrappers. > > If we couldn't find a solution, it would be nice to have an > explaining > comment at this place. > > > > > If Eric or anybody else has another way to fix await completion > > that > > will actually work, I'm more then willing to do it that way. > > Regarding to my comments it's okay to keep the memdump and introduce > the > Kconfig parameter for all dumps later. > > Stefan I'll go ahead and add more explaining comments and the Kconfig for memdump that defaults to off. Then if Raspbian needs the ability to support memdump, they can turn it back on. I have absolutely no problem doing either of those. Dan and Eric have a few simple fixes that I can include in V5 as well. I'll go ahead and resend that in a day or two. Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t
Hello.
On 03/06/2017 05:20 PM, Elena Reshetova wrote:
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
[...]
diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index 115414c..16c1313 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -339,7 +340,7 @@ struct cx8802_dev;
struct cx88_core {
struct list_head devlist;
- atomic_t refcount;
+ refcount_t refcount;
Could you please keep the name aligned with above and below?
/* board name */
intnr;
MBR, Sergei
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
On Mon, Mar 06, 2017 at 04:27:11PM +0100, Johannes Thumshirn wrote: > On 03/06/2017 03:21 PM, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > The subject is wrong, should be something like "scsi: libfc convert > fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390. > Yes please, I was extremely confused for a moment here. Beste Grüße / Best regards, - Benjamin Block -- Linux on z Systems Development / IBM Systems & Technology Group IBM Deutschland Research & Development GmbH Vorsitz. AufsR.: Martina Koederitz /Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t
On 03/06/2017 09:21 AM, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova > Signed-off-by: Hans Liljestrand > Signed-off-by: Kees Cook > Signed-off-by: David Windsor > --- > drivers/xen/gntdev.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) Reviewed-by: Boris Ostrovsky ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support
On 6 March 2017 at 10:29, Daniel Vetter wrote:
> On Fri, Mar 03, 2017 at 10:46:03AM -0800, Laura Abbott wrote:
>> On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
>> > Hi Daniel,
>> >
>> > On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
>> >> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
>> >>> Now that we call dma_map in the dma_buf API callbacks there is no need
>> >>> to use the existing cache APIs. Remove the sync ioctl and the existing
>> >>> bad dma_sync calls. Explicit caching can be handled with the dma_buf
>> >>> sync API.
>> >>>
>> >>> Signed-off-by: Laura Abbott
>> >>> ---
>> >>>
>> >>> drivers/staging/android/ion/ion-ioctl.c | 5
>> >>> drivers/staging/android/ion/ion.c | 40
>> >>>
>> >>> drivers/staging/android/ion/ion_carveout_heap.c | 6
>> >>> drivers/staging/android/ion/ion_chunk_heap.c| 6
>> >>> drivers/staging/android/ion/ion_page_pool.c | 3 --
>> >>> drivers/staging/android/ion/ion_system_heap.c | 5
>> >>> 6 files changed, 65 deletions(-)
>> >>>
>> >>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
>> >>> b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
>> >>> --- a/drivers/staging/android/ion/ion-ioctl.c
>> >>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>> >>> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
>> >>> unsigned long arg)>
>> >>> data.handle.handle = handle->id;
>> >>>
>> >>> break;
>> >>>
>> >>> }
>> >>>
>> >>> - case ION_IOC_SYNC:
>> >>> - {
>> >>> - ret = ion_sync_for_device(client, data.fd.fd);
>> >>> - break;
>> >>> - }
>> >>
>> >> You missed the case ION_IOC_SYNC: in compat_ion.c.
>> >>
>> >> While at it: Should we also remove the entire custom_ioctl infrastructure?
>> >> It's entirely unused afaict, and for a pure buffer allocator I don't see
>> >> any need to have custom ioctl.
>> >
>> > I second that, if you want to make ion a standard API, then we certainly
>> > don't
>> > want any custom ioctl.
>> >
>> >> More code to remove potentially:
>> >> - The entire compat ioctl stuff - would be an abi break, but I guess if we
>> >> pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
>> >> would allow us to remove compat_ion.c entirely.
>> >>
>> >> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
>> >> still need to be able to import anything. All the cache flushing/mapping
>> >> is done through dma-buf ops/ioctls.
>> >>
>> >>
>>
>> Good point to all of the above. I was considering keeping the import around
>> for backwards compatibility reasons but given how much other stuff is being
>> potentially broken, everything should just get ripped out.
>
> If you're ok with breaking the world, then I strongly suggest we go
> through the uapi header and replace all types with the standard
> fixed-width ones (__s32, __s64 and __u32, __u64). Allows us to remove all
> the compat ioctl code :-)
I think the other comments from your "botching-up ioctls" [1] also apply ;-)
Namely - align structs to multiple of 64bit, add "flags" and properly
verity user input returning -EINVAL.
-Emil
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature
On 03/04/2017 04:11 AM, Borislav Petkov wrote: > On Fri, Mar 03, 2017 at 03:01:23PM -0600, Brijesh Singh wrote: > > This looks like a wraparound... > > $ test-apply.sh /tmp/brijesh.singh.delta > checking file Documentation/admin-guide/kernel-parameters.txt > Hunk #1 succeeded at 2144 (offset -9 lines). > checking file Documentation/x86/amd-memory-encryption.txt > patch: malformed patch at line 23: DRAM from physical > > Yap. > > Looks like exchange or your mail client decided to do some patch editing > on its own. > > Please send it to yourself first and try applying. > Sending it through stg mail to avoid line wrapping. Please let me know if something is still messed up. I have tried applying it and it seems to apply okay. --- Documentation/admin-guide/kernel-parameters.txt |4 +-- Documentation/x86/amd-memory-encryption.txt | 33 +-- arch/x86/include/asm/cpufeature.h |7 + arch/x86/include/asm/cpufeatures.h |6 +--- arch/x86/include/asm/disabled-features.h|3 +- arch/x86/include/asm/required-features.h|3 +- arch/x86/kernel/cpu/amd.c | 23 arch/x86/kernel/cpu/common.c| 23 arch/x86/kernel/cpu/scattered.c |1 + 9 files changed, 50 insertions(+), 53 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 91c40fa..b91e2495 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2153,8 +2153,8 @@ mem_encrypt=on: Activate SME mem_encrypt=off:Do not activate SME - Refer to the SME documentation for details on when - memory encryption can be activated. + Refer to Documentation/x86/amd-memory-encryption.txt + for details on when memory encryption can be activated. mem_sleep_default= [SUSPEND] Default system suspend mode: s2idle - Suspend-To-Idle diff --git a/Documentation/x86/amd-memory-encryption.txt b/Documentation/x86/amd-memory-encryption.txt index 0938e89..0b72ff2 100644 --- a/Documentation/x86/amd-memory-encryption.txt +++ b/Documentation/x86/amd-memory-encryption.txt @@ -7,9 +7,9 @@ DRAM. SME can therefore be used to protect the contents of DRAM from physical attacks on the system. A page is encrypted when a page table entry has the encryption bit set (see -below how to determine the position of the bit). The encryption bit can be -specified in the cr3 register, allowing the PGD table to be encrypted. Each -successive level of page tables can also be encrypted. +below on how to determine its position). The encryption bit can be specified +in the cr3 register, allowing the PGD table to be encrypted. Each successive +level of page tables can also be encrypted. Support for SME can be determined through the CPUID instruction. The CPUID function 0x801f reports information related to SME: @@ -17,13 +17,14 @@ function 0x801f reports information related to SME: 0x801f[eax]: Bit[0] indicates support for SME 0x801f[ebx]: - Bit[5:0] pagetable bit number used to activate memory - encryption - Bit[11:6] reduction in physical address space, in bits, when - memory encryption is enabled (this only affects system - physical addresses, not guest physical addresses) - -If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to + Bits[5:0] pagetable bit number used to activate memory + encryption + Bits[11:6] reduction in physical address space, in bits, when + memory encryption is enabled (this only affects + system physical addresses, not guest physical + addresses) + +If support for SME is present, MSR 0xc00100010 (MSR_K8_SYSCFG) can be used to determine if SME is enabled and/or to enable memory encryption: 0xc0010010: @@ -41,7 +42,7 @@ The state of SME in the Linux kernel can be documented as follows: The CPU supports SME (determined through CPUID instruction). - Enabled: - Supported and bit 23 of the SYS_CFG MSR is set. + Supported and bit 23 of MSR_K8_SYSCFG is set. - Active: Supported, Enabled and the Linux kernel is actively applying @@ -51,7 +52,9 @@ The state of SME in the Linux kernel can be documented as follows: SME can also be enabled and activated in the BIOS. If SME is enabled and activated in the BIOS, then all memory accesses will be encrypted and it will not be necessary to activate the Linux memory encrypt
Re: [PATCH 5/5] staging: lustre: osc_page.c: Use list_for_each_entry_safe
On Mon, Mar 6, 2017 at 8:50 PM, James Simmons wrote:
>
>> Doubly linked lists which are iterated using list_empty
>> and list_entry macros have been replaced with list_for_each_entry_safe
>> macro.
>> This makes the iteration simpler and more readable.
>>
>> This patch replaces the while loop containing list_empty and list_entry
>> with list_for_each_entry_safe.
>>
>> This was done with Coccinelle.
>>
>> @@
>> expression E1;
>> identifier I1, I2;
>> type T;
>> iterator name list_for_each_entry_safe;
>> @@
>>
>> T *I1;
>> + T *tmp;
>> ...
>> - while (list_empty(&E1) == 0)
>> + list_for_each_entry_safe (I1, tmp, &E1, I2)
>> {
>> ...when != T *I1;
>> - I1 = list_entry(E1.next, T, I2);
>> ...
>> }
>>
>> Signed-off-by: simran singhal
>
> NAK!!
>
> This change was reverted in commit
>
> cd15dd6ef4ea11df87f717b8b1b83aaa738ec8af
>
> Doing these while (list_empty(..)) to list_for_entry...
> are not simple changes and have broken things in lustre
> before. Unless you really understand the state machine of
> the lustre code I don't recommend these kinds of change
> for lustre.
>
Is this for this particular patch or for all the patches of this patch-series.
>> ---
>> drivers/staging/lustre/lustre/osc/osc_page.c | 11 ---
>> 1 file changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/staging/lustre/lustre/osc/osc_page.c
>> b/drivers/staging/lustre/lustre/osc/osc_page.c
>> index ed8a0dc..e8b974f 100644
>> --- a/drivers/staging/lustre/lustre/osc/osc_page.c
>> +++ b/drivers/staging/lustre/lustre/osc/osc_page.c
>> @@ -542,6 +542,7 @@ long osc_lru_shrink(const struct lu_env *env, struct
>> client_obd *cli,
>> struct cl_object *clobj = NULL;
>> struct cl_page **pvec;
>> struct osc_page *opg;
>> + struct osc_page *tmp;
>> int maxscan = 0;
>> long count = 0;
>> int index = 0;
>> @@ -572,7 +573,7 @@ long osc_lru_shrink(const struct lu_env *env, struct
>> client_obd *cli,
>> if (force)
>> cli->cl_lru_reclaim++;
>> maxscan = min(target << 1, atomic_long_read(&cli->cl_lru_in_list));
>> - while (!list_empty(&cli->cl_lru_list)) {
>> + list_for_each_entry_safe(opg, tmp, &cli->cl_lru_list, ops_lru) {
>> struct cl_page *page;
>> bool will_free = false;
>>
>> @@ -582,8 +583,6 @@ long osc_lru_shrink(const struct lu_env *env, struct
>> client_obd *cli,
>> if (--maxscan < 0)
>> break;
>>
>> - opg = list_entry(cli->cl_lru_list.next, struct osc_page,
>> - ops_lru);
>> page = opg->ops_cl.cpl_page;
>> if (lru_page_busy(cli, page)) {
>> list_move_tail(&opg->ops_lru, &cli->cl_lru_list);
>> @@ -1043,6 +1042,7 @@ unsigned long osc_cache_shrink_scan(struct shrinker
>> *sk,
>> {
>> struct client_obd *stop_anchor = NULL;
>> struct client_obd *cli;
>> + struct client_obd *tmp;
>> struct lu_env *env;
>> long shrank = 0;
>> u16 refcheck;
>> @@ -1059,10 +1059,7 @@ unsigned long osc_cache_shrink_scan(struct shrinker
>> *sk,
>> return SHRINK_STOP;
>>
>> spin_lock(&osc_shrink_lock);
>> - while (!list_empty(&osc_shrink_list)) {
>> - cli = list_entry(osc_shrink_list.next, struct client_obd,
>> - cl_shrink_list);
>> -
>> + list_for_each_entry_safe(cli, tmp, &osc_shrink_list, cl_shrink_list) {
>> if (!stop_anchor)
>> stop_anchor = cli;
>> else if (cli == stop_anchor)
>> --
>> 2.7.4
>>
>>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly
On 03/06/2017 07:52 AM, Daniel Vetter wrote: > On Mon, Mar 06, 2017 at 03:43:53PM +0200, Laurent Pinchart wrote: >> Hi Daniel, >> >> On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote: >>> On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote: On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: >> When CMA was first introduced, its primary use was for DMA allocation >> and the only way to get CMA memory was to call dma_alloc_coherent. This >> put Ion in an awkward position since there was no device structure >> readily available and setting one up messed up the coherency model. >> These days, CMA can be allocated directly from the APIs. Switch to >> using this model to avoid needing a dummy device. This also avoids >> awkward caching questions. > > If the DMA mapping API isn't suitable for today's requirements anymore, > I believe that's what needs to be fixed, instead of working around the > problem by introducing another use-case-specific API. I don't think this is a usecase specific API. CMA has been decoupled from DMA already because it's used in other places. The trying to go through DMA was just another layer of abstraction, especially since there isn't a device available for allocation. >>> >>> Also, we've had separation of allocation and dma-mapping since forever, >>> that's how it works almost everywhere. Not exactly sure why/how arm-soc >>> ecosystem ended up focused so much on dma_alloc_coherent. >> >> I believe because that was the easy way to specify memory constraints. The >> API >> receives a device pointer and will allocate memory suitable for DMA for that >> device. The fact that it maps it to the device is a side-effect in my >> opinion. >> Agreed. The device Ion wanted to use was never a real device though so any constraints it satisfied were making assumptions about what memory would be allocated. >>> I think separating allocation from dma mapping/coherency is perfectly >>> fine, and the way to go. >> >> Especially given that in many cases we'll want to share buffers between >> multiple devices, so we'll need to map them multiple times. >> >> My point still stands though, if we want to move towards a model where >> allocation and mapping are decoupled, we need an allocation function that >> takes constraints (possibly implemented with two layers, a constraint >> resolution layer on top of a pool/heap/type/foo-based allocator), and a >> mapping API. IOMMU handling being integrated in the DMA mapping API we're >> currently stuck with it, which might call for brushing up that API. > > Hm, maybe I wasn't clear, but that's exactly what I assume will happen: > > The constraint resolver is the unix device memory allocation thing, which > happens entirely in userspace. There's a lot more than just "where to > allocate" to negotiate, e.g. pixel format, stride/size > limits/requirements, tiling formats. A lot of it the kernel doesn't even > know. > > Allocation then needs to happen through the kernel ofc, but that doesn't > mean we need to have all the constraint resolving in the kernel. As long > as the kernel exposes the device /dev node -> ion heap stuff, userspace > can figure this out. Or an alternative way would be to have a cascade of > ion heaps to keep things a notch more opaque. Either way, no actaul > constraint resolving in the kernel itself, and except for a bunch more > stuff in sysfs maybe, also no other uapi changes. Once we have a place to > allocate stuff which isn't the device driver at least, aka ION. > > And then once allocated you use the dma apis to instantiate the iommus > mappings. > > Anyway, at least from my understanding I think there's 0 risk with merging > ION wrt the constraint resolving side (at least as discussed around XDC > last year), and for setups that need cma, it might finally enable to get > things moving forward. > > Or do I miss something big here? > -Daniel > This all sounds like what I was thinking. I think some of the concerns may be that the details of constraint solving are mostly handwaving right now. Thanks, Laura ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] Fix coding style errors
This patch fixes two conding style errors, reported by the checkpatch
script.
Signed-off-by: Elia Geretto
---
drivers/staging/rtl8192u/r8192U_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index b631990..b61ffa3 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -269,7 +269,7 @@ int write_nic_byte_E(struct net_device *dev, int indx, u8
data)
indx | 0xfe00, 0, usbdata, 1, HZ / 2);
kfree(usbdata);
- if (status < 0){
+ if (status < 0) {
netdev_err(dev, "write_nic_byte_E TimeOut! status: %d\n",
status);
return status;
@@ -2519,7 +2519,7 @@ static int rtl8192_read_eeprom_info(struct net_device
*dev)
for (i = 0; i < 3; i++) {
if (bLoad_From_EEPOM) {
ret = eprom_read(dev,
(EEPROM_TxPwIndex_OFDM_24G + i) >> 1);
- if ( ret < 0)
+ if (ret < 0)
return ret;
if (((EEPROM_TxPwIndex_OFDM_24G + i) %
2) == 0)
tmpValue = (u16)ret & 0x00ff;
--
2.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support
On 03/06/2017 09:00 AM, Emil Velikov wrote:
> On 6 March 2017 at 10:29, Daniel Vetter wrote:
>> On Fri, Mar 03, 2017 at 10:46:03AM -0800, Laura Abbott wrote:
>>> On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
Hi Daniel,
On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
>> Now that we call dma_map in the dma_buf API callbacks there is no need
>> to use the existing cache APIs. Remove the sync ioctl and the existing
>> bad dma_sync calls. Explicit caching can be handled with the dma_buf
>> sync API.
>>
>> Signed-off-by: Laura Abbott
>> ---
>>
>> drivers/staging/android/ion/ion-ioctl.c | 5
>> drivers/staging/android/ion/ion.c | 40
>>
>> drivers/staging/android/ion/ion_carveout_heap.c | 6
>> drivers/staging/android/ion/ion_chunk_heap.c| 6
>> drivers/staging/android/ion/ion_page_pool.c | 3 --
>> drivers/staging/android/ion/ion_system_heap.c | 5
>> 6 files changed, 65 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
>> b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
>> --- a/drivers/staging/android/ion/ion-ioctl.c
>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
>> unsigned long arg)>
>> data.handle.handle = handle->id;
>>
>> break;
>>
>> }
>>
>> - case ION_IOC_SYNC:
>> - {
>> - ret = ion_sync_for_device(client, data.fd.fd);
>> - break;
>> - }
>
> You missed the case ION_IOC_SYNC: in compat_ion.c.
>
> While at it: Should we also remove the entire custom_ioctl infrastructure?
> It's entirely unused afaict, and for a pure buffer allocator I don't see
> any need to have custom ioctl.
I second that, if you want to make ion a standard API, then we certainly
don't
want any custom ioctl.
> More code to remove potentially:
> - The entire compat ioctl stuff - would be an abi break, but I guess if we
> pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
> would allow us to remove compat_ion.c entirely.
>
> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
> still need to be able to import anything. All the cache flushing/mapping
> is done through dma-buf ops/ioctls.
>
>
>>>
>>> Good point to all of the above. I was considering keeping the import around
>>> for backwards compatibility reasons but given how much other stuff is being
>>> potentially broken, everything should just get ripped out.
>>
>> If you're ok with breaking the world, then I strongly suggest we go
>> through the uapi header and replace all types with the standard
>> fixed-width ones (__s32, __s64 and __u32, __u64). Allows us to remove all
>> the compat ioctl code :-)
>
> I think the other comments from your "botching-up ioctls" [1] also apply ;-)
> Namely - align structs to multiple of 64bit, add "flags" and properly
> verity user input returning -EINVAL.
>
> -Emil
>
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt
I'm more torn on this. There's a difference between dropping an old
ioctl/implicit caching vs. changing an actual ioctl ABI.
Maybe having obvious breakage is better than subtle though,
plus nobody has come begging me not to break the ABI yet.
I might leave this for right before we do the actual move
out of staging.
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vchiq_utils: Don't include headers twice
There is no need to include types.h and vmalloc.h twice. This issue has been found by make includecheck. Signed-off-by: Stefan Wahren --- .../vc04_services/interface/vchiq_arm/vchiq_util.h |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.h index e63964f..5a1540d 100644 --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.h +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.h @@ -44,7 +44,6 @@ #include #include #include -#include #include #include #include @@ -52,7 +51,6 @@ #include #include /* for time_t */ #include -#include #include "vchiq_if.h" -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] staging: sm750fb: fixes add blank line after function/struct/union/enum declarations
Hi Arushi,
On Sun, Mar 5, 2017 at 12:24 PM, Arushi Singhal
wrote:
> This patch fixes the warnings reported by checkpatch.pl
> for please use a blank line after function/struct/union/enum
> declarations.
>
> Signed-off-by: Arushi Singhal
> ---
> drivers/staging/sm750fb/ddk750_display.h | 1 +
> drivers/staging/sm750fb/ddk750_mode.h| 2 ++
> drivers/staging/sm750fb/ddk750_power.h | 1 +
> drivers/staging/sm750fb/sm750_cursor.c | 3 +++
> 4 files changed, 7 insertions(+)
>
> diff --git a/drivers/staging/sm750fb/ddk750_display.h
> b/drivers/staging/sm750fb/ddk750_display.h
> index e2a3f84ca4c5..8bf22e4f0d8b 100644
> --- a/drivers/staging/sm750fb/ddk750_display.h
> +++ b/drivers/staging/sm750fb/ddk750_display.h
> @@ -100,6 +100,7 @@ typedef enum _disp_output_t {
> do_CRT_PRI = CRT_2_PRI | PRI_TP_ON | DPMS_ON | DAC_ON,
> do_CRT_SEC = CRT_2_SEC | SEC_TP_ON | DPMS_ON | DAC_ON,
> }
> +
> disp_output_t;
That's a false positive. Actually "disp_output_t" should be on the
previous line,
after the closing curly brace, as variable types and names must not be split.
> --- a/drivers/staging/sm750fb/ddk750_mode.h
> +++ b/drivers/staging/sm750fb/ddk750_mode.h
> @@ -7,6 +7,7 @@ typedef enum _spolarity_t {
> POS = 0, /* positive */
> NEG, /* negative */
> }
> +
> spolarity_t;
>
> typedef struct _mode_parameter_t {
> @@ -32,6 +33,7 @@ typedef struct _mode_parameter_t {
> /* Clock Phase. This clock phase only applies to Panel. */
> spolarity_t clock_phase_polarity;
> }
> +
> mode_parameter_t;
Likewise.
> --- a/drivers/staging/sm750fb/ddk750_power.h
> +++ b/drivers/staging/sm750fb/ddk750_power.h
> @@ -7,6 +7,7 @@ typedef enum _DPMS_t {
> crtDPMS_SUSPEND = 0x2,
> crtDPMS_OFF = 0x3,
> }
> +
> DPMS_t;
Likewise.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature
On Mon, Mar 06, 2017 at 01:11:03PM -0500, Brijesh Singh wrote: > Sending it through stg mail to avoid line wrapping. Please let me know if > something > is still messed up. I have tried applying it and it seems to apply okay. Yep, thanks. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wilc1000: Fix sparse warnings incorrect type assignment
Fixed sparse warnings
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2011:52: warning: incorrect
type in assignment (different base types)
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2011:52:expected
unsigned short [unsigned] [assigned] [usertype] ht_ext_params
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2011:52:got restricted
__le16 const [usertype] extended_ht_cap_info
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2012:51: warning: incorrect
type in assignment (different base types)
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2012:51:expected
unsigned int [unsigned] [assigned] [usertype] ht_tx_bf_cap
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2012:51:got restricted
__le32 const [usertype] tx_BF_cap_info
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2078:51: warning: incorrect
type in assignment (different base types)
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2078:51:expected
unsigned short [unsigned] [assigned] [usertype] ht_capa_info
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2078:51:got restricted
__le16 const [usertype] cap_info
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2083:52: warning: incorrect
type in assignment (different base types)
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2083:52:expected
unsigned short [unsigned] [assigned] [usertype] ht_ext_params
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2083:52:got restricted
__le16 const [usertype] extended_ht_cap_info
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2084:51: warning: incorrect
type in assignment (different base types)
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2084:51:expected
unsigned int [unsigned] [assigned] [usertype] ht_tx_bf_cap
drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2084:51:got restricted
__le32 const [usertype] tx_BF_cap_info
Signed-off-by: Andrea Ghittino
---
Compile tested only
wilc_wfi_cfgoperations.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 7961d1c..d3b5ac8 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -2003,13 +2003,13 @@ static int add_station(struct wiphy *wiphy, struct
net_device *dev,
strStaParams.ht_supported = false;
} else {
strStaParams.ht_supported = true;
- strStaParams.ht_capa_info = params->ht_capa->cap_info;
+ strStaParams.ht_capa_info =
le16_to_cpu(params->ht_capa->cap_info);
strStaParams.ht_ampdu_params =
params->ht_capa->ampdu_params_info;
memcpy(strStaParams.ht_supp_mcs_set,
¶ms->ht_capa->mcs,
WILC_SUPP_MCS_SET_SIZE);
- strStaParams.ht_ext_params =
params->ht_capa->extended_ht_cap_info;
- strStaParams.ht_tx_bf_cap =
params->ht_capa->tx_BF_cap_info;
+ strStaParams.ht_ext_params =
le16_to_cpu(params->ht_capa->extended_ht_cap_info);
+ strStaParams.ht_tx_bf_cap =
le32_to_cpu(params->ht_capa->tx_BF_cap_info);
strStaParams.ht_ante_sel =
params->ht_capa->antenna_selection_info;
}
@@ -2075,13 +2075,13 @@ static int change_station(struct wiphy *wiphy, struct
net_device *dev,
strStaParams.ht_supported = false;
} else {
strStaParams.ht_supported = true;
- strStaParams.ht_capa_info = params->ht_capa->cap_info;
+ strStaParams.ht_capa_info =
le16_to_cpu(params->ht_capa->cap_info);
strStaParams.ht_ampdu_params =
params->ht_capa->ampdu_params_info;
memcpy(strStaParams.ht_supp_mcs_set,
¶ms->ht_capa->mcs,
WILC_SUPP_MCS_SET_SIZE);
- strStaParams.ht_ext_params =
params->ht_capa->extended_ht_cap_info;
- strStaParams.ht_tx_bf_cap =
params->ht_capa->tx_BF_cap_info;
+ strStaParams.ht_ext_params =
le16_to_cpu(params->ht_capa->extended_ht_cap_info);
+ strStaParams.ht_tx_bf_cap =
le32_to_cpu(params->ht_capa->tx_BF_cap_info);
strStaParams.ht_ante_sel =
params->ht_capa->antenna_selection_info;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 17/29] drivers, pci: convert hv_pci_dev.refs from atomic_t to refcount_t
[+cc Hyper-V folks, -cc others]
On Mon, Mar 06, 2017 at 04:21:04PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova
> Signed-off-by: Hans Liljestrand
> Signed-off-by: Kees Cook
> Signed-off-by: David Windsor
> ---
> drivers/pci/host/pci-hyperv.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index cd114c6..870deed 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -56,6 +56,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /*
> @@ -421,7 +422,7 @@ enum hv_pcidev_ref_reason {
> struct hv_pci_dev {
> /* List protected by pci_rescan_remove_lock */
> struct list_head list_entry;
> - atomic_t refs;
> + refcount_t refs;
> enum hv_pcichild_state state;
> struct pci_function_description desc;
> bool reported_missing;
> @@ -1254,13 +1255,13 @@ static void q_resource_requirements(void *context,
> struct pci_response *resp,
> static void get_pcichild(struct hv_pci_dev *hpdev,
> enum hv_pcidev_ref_reason reason)
> {
> - atomic_inc(&hpdev->refs);
> + refcount_inc(&hpdev->refs);
> }
>
> static void put_pcichild(struct hv_pci_dev *hpdev,
> enum hv_pcidev_ref_reason reason)
> {
> - if (atomic_dec_and_test(&hpdev->refs))
> + if (refcount_dec_and_test(&hpdev->refs))
> kfree(hpdev);
> }
>
> @@ -1314,7 +1315,7 @@ static struct hv_pci_dev *new_pcichild_device(struct
> hv_pcibus_device *hbus,
> wait_for_completion(&comp_pkt.host_event);
>
> hpdev->desc = *desc;
> - get_pcichild(hpdev, hv_pcidev_ref_initial);
> + refcount_set(&hpdev->refs, 1);
> get_pcichild(hpdev, hv_pcidev_ref_childlist);
> spin_lock_irqsave(&hbus->device_list_lock, flags);
> list_add_tail(&hpdev->list_entry, &hbus->children);
> --
> 2.7.4
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: ks7010: make whitespace changes
Function ks_sdio_interrupt may be refactored after previous patch
reduced the level of indentation in the function.
Refactor function inline with kernel coding style. Make only white
space changes. Do not alter the program logic.
Signed-off-by: Tobin C. Harding
---
drivers/staging/ks7010/ks7010_sdio.c | 45 +++-
1 file changed, 18 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/ks7010/ks7010_sdio.c
b/drivers/staging/ks7010/ks7010_sdio.c
index cb7dc2e..18309ba 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -547,9 +547,7 @@ static void ks_sdio_interrupt(struct sdio_func *func)
if (priv->dev_state < DEVICE_STATE_BOOT)
goto intr_out;
- retval =
- ks7010_sdio_read(priv, INT_PENDING, &status,
- sizeof(status));
+ retval = ks7010_sdio_read(priv, INT_PENDING, &status, sizeof(status));
if (retval) {
DPRINTK(1, "read INT_PENDING Failed!!(%d)\n", retval);
goto intr_out;
@@ -561,21 +559,18 @@ static void ks_sdio_interrupt(struct sdio_func *func)
/* read (General Communication B register) */
/* bit5 -> Write Status Idle */
/* bit2 -> Read Status Busy */
- if (status & INT_GCR_B
- || atomic_read(&priv->psstatus.status) == PS_SNOOZE) {
- retval =
- ks7010_sdio_read(priv, GCR_B, &rw_data,
- sizeof(rw_data));
+ if (status & INT_GCR_B ||
+ atomic_read(&priv->psstatus.status) == PS_SNOOZE) {
+ retval = ks7010_sdio_read(priv, GCR_B, &rw_data,
+ sizeof(rw_data));
if (retval) {
DPRINTK(1, " error : GCR_B=%02X\n", rw_data);
goto intr_out;
}
/* DPRINTK(1, "GCR_B=%02X\n", rw_data); */
if (rw_data == GCR_B_ACTIVE) {
- if (atomic_read(&priv->psstatus.status) ==
- PS_SNOOZE) {
- atomic_set(&priv->psstatus.status,
- PS_WAKEUP);
+ if (atomic_read(&priv->psstatus.status) == PS_SNOOZE) {
+ atomic_set(&priv->psstatus.status, PS_WAKEUP);
priv->wakeup_count = 0;
}
complete(&priv->psstatus.wakeup_wait);
@@ -584,30 +579,26 @@ static void ks_sdio_interrupt(struct sdio_func *func)
do {
/* read (WriteStatus/ReadDataSize FN1:00_0014) */
- retval =
- ks7010_sdio_read(priv, WSTATUS_RSIZE, &rw_data,
- sizeof(rw_data));
+ retval = ks7010_sdio_read(priv, WSTATUS_RSIZE, &rw_data,
+ sizeof(rw_data));
if (retval) {
- DPRINTK(1, " error : WSTATUS_RSIZE=%02X\n",
- rw_data);
+ DPRINTK(1, " error : WSTATUS_RSIZE=%02X\n", rw_data);
goto intr_out;
}
DPRINTK(4, "WSTATUS_RSIZE=%02X\n", rw_data);
rsize = rw_data & RSIZE_MASK;
- if (rsize) {/* Read schedule */
- ks_wlan_hw_rx((void *)priv,
- (uint16_t)(rsize << 4));
- }
+ if (rsize) /* Read schedule */
+ ks_wlan_hw_rx((void *)priv, (uint16_t)(rsize << 4));
+
if (rw_data & WSTATUS_MASK) {
#if 0
- if (status & INT_WRITE_STATUS
- && !cnt_txqbody(priv)) {
+ if (status & INT_WRITE_STATUS &&
+ !cnt_txqbody(priv)) {
/* dummy write for interrupt clear */
rw_data = 0;
- retval =
- ks7010_sdio_write(priv, DATA_WINDOW,
- &rw_data,
- sizeof(rw_data));
+ retval = ks7010_sdio_write(priv, DATA_WINDOW,
+ &rw_data,
+ sizeof(rw_data));
if (retval) {
DPRINTK(1,
"write DATA_WINDOW
Failed!!(%d)\n",
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] staging: ks7010: add additional goto target
Function contains multiple return sites. Function already contains a
goto target that makes a function call before returning, the same
function is called (with different arguments) before returning at an
internal location. It would be clearer if both functions were called
at the same place and labelled for use with goto.
Add additional goto target and remove multiple return sites. As a
bonus clear three checkpatch warnings (line over 80 and multi-line
dereference).
Signed-off-by: Tobin C. Harding
---
drivers/staging/ks7010/ks7010_sdio.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/ks7010/ks7010_sdio.c
b/drivers/staging/ks7010/ks7010_sdio.c
index 18309ba..ff2af9f 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -545,12 +545,12 @@ static void ks_sdio_interrupt(struct sdio_func *func)
DPRINTK(4, "\n");
if (priv->dev_state < DEVICE_STATE_BOOT)
- goto intr_out;
+ goto intr_out_no_delay;
retval = ks7010_sdio_read(priv, INT_PENDING, &status, sizeof(status));
if (retval) {
DPRINTK(1, "read INT_PENDING Failed!!(%d)\n", retval);
- goto intr_out;
+ goto intr_out_no_delay;
}
DPRINTK(4, "INT_PENDING=%02X\n", rw_data);
@@ -565,7 +565,7 @@ static void ks_sdio_interrupt(struct sdio_func *func)
sizeof(rw_data));
if (retval) {
DPRINTK(1, " error : GCR_B=%02X\n", rw_data);
- goto intr_out;
+ goto intr_out_no_delay;
}
/* DPRINTK(1, "GCR_B=%02X\n", rw_data); */
if (rw_data == GCR_B_ACTIVE) {
@@ -583,7 +583,7 @@ static void ks_sdio_interrupt(struct sdio_func *func)
sizeof(rw_data));
if (retval) {
DPRINTK(1, " error : WSTATUS_RSIZE=%02X\n", rw_data);
- goto intr_out;
+ goto intr_out_no_delay;
}
DPRINTK(4, "WSTATUS_RSIZE=%02X\n", rw_data);
rsize = rw_data & RSIZE_MASK;
@@ -610,12 +610,7 @@ static void ks_sdio_interrupt(struct sdio_func *func)
if (atomic_read(&priv->psstatus.status) ==
PS_SNOOZE) {
if (cnt_txqbody(priv)) {
ks_wlan_hw_wakeup_request(priv);
- queue_delayed_work
- (priv->ks_wlan_hw.
- ks7010sdio_wq,
-
&priv->ks_wlan_hw.
- rw_wq, 1);
- return;
+ goto intr_out_with_delay;
}
} else {
tx_device_task((void *)priv);
@@ -626,9 +621,13 @@ static void ks_sdio_interrupt(struct sdio_func *func)
}
} while (rsize);
- intr_out:
+ intr_out_no_delay:
queue_delayed_work(priv->ks_wlan_hw.ks7010sdio_wq,
&priv->ks_wlan_hw.rw_wq, 0);
+ return;
+ intr_out_with_delay:
+ queue_delayed_work(priv->ks_wlan_hw.ks7010sdio_wq,
+ &priv->ks_wlan_hw.rw_wq, 1);
}
static int trx_device_init(struct ks_wlan_private *priv)
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/3] clean up ks_sdio_interrupt()
Checkpatch emits various warnings relating to function ks_sdio_interrupt(). Function is deeply nested. First reduce the indentation. Next make some whitespace changes, refactoring in line with kernel coding style. Lastly add an additional goto target, removing internal return's and clearing three checkpatch warnings. Tobin C. Harding (3): staging: ks7010: remove one level of indentation staging: ks7010: make whitespace changes staging: ks7010: add additional goto target drivers/staging/ks7010/ks7010_sdio.c | 153 +-- 1 file changed, 72 insertions(+), 81 deletions(-) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: ks7010: remove one level of indentation
Function ks_sdio_interrupt() is deeply nested. One level of indentation
may be removed by inverting an 'if' statement conditional. Body of
statement makes up the bulk of the function. Goto can be used to
return early from function. It is not necessary to alter the function
logic. Once completed, this will open the way for further refactoring.
Invert conditional. Add goto statement to return from function if new
conditional evaluates true. Reduce level of indentation by one. Do not
alter program logic.
Signed-off-by: Tobin C. Harding
---
drivers/staging/ks7010/ks7010_sdio.c | 157 ++-
1 file changed, 79 insertions(+), 78 deletions(-)
diff --git a/drivers/staging/ks7010/ks7010_sdio.c
b/drivers/staging/ks7010/ks7010_sdio.c
index 14580cb..cb7dc2e 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -1,4 +1,4 @@
-/*
+r/*
* Driver for KeyStream, KS7010 based SDIO cards.
*
* Copyright (C) 2006-2008 KeyStream Corp.
@@ -544,95 +544,96 @@ static void ks_sdio_interrupt(struct sdio_func *func)
priv = card->priv;
DPRINTK(4, "\n");
- if (priv->dev_state >= DEVICE_STATE_BOOT) {
+ if (priv->dev_state < DEVICE_STATE_BOOT)
+ goto intr_out;
+
+ retval =
+ ks7010_sdio_read(priv, INT_PENDING, &status,
+ sizeof(status));
+ if (retval) {
+ DPRINTK(1, "read INT_PENDING Failed!!(%d)\n", retval);
+ goto intr_out;
+ }
+ DPRINTK(4, "INT_PENDING=%02X\n", rw_data);
+
+ /* schedule task for interrupt status */
+ /* bit7 -> Write General Communication B register */
+ /* read (General Communication B register) */
+ /* bit5 -> Write Status Idle */
+ /* bit2 -> Read Status Busy */
+ if (status & INT_GCR_B
+ || atomic_read(&priv->psstatus.status) == PS_SNOOZE) {
retval =
- ks7010_sdio_read(priv, INT_PENDING, &status,
-sizeof(status));
+ ks7010_sdio_read(priv, GCR_B, &rw_data,
+ sizeof(rw_data));
if (retval) {
- DPRINTK(1, "read INT_PENDING Failed!!(%d)\n", retval);
+ DPRINTK(1, " error : GCR_B=%02X\n", rw_data);
goto intr_out;
}
- DPRINTK(4, "INT_PENDING=%02X\n", rw_data);
-
- /* schedule task for interrupt status */
- /* bit7 -> Write General Communication B register */
- /* read (General Communication B register) */
- /* bit5 -> Write Status Idle */
- /* bit2 -> Read Status Busy */
- if (status & INT_GCR_B
- || atomic_read(&priv->psstatus.status) == PS_SNOOZE) {
- retval =
- ks7010_sdio_read(priv, GCR_B, &rw_data,
-sizeof(rw_data));
- if (retval) {
- DPRINTK(1, " error : GCR_B=%02X\n", rw_data);
- goto intr_out;
- }
- /* DPRINTK(1, "GCR_B=%02X\n", rw_data); */
- if (rw_data == GCR_B_ACTIVE) {
- if (atomic_read(&priv->psstatus.status) ==
- PS_SNOOZE) {
- atomic_set(&priv->psstatus.status,
- PS_WAKEUP);
- priv->wakeup_count = 0;
- }
- complete(&priv->psstatus.wakeup_wait);
+ /* DPRINTK(1, "GCR_B=%02X\n", rw_data); */
+ if (rw_data == GCR_B_ACTIVE) {
+ if (atomic_read(&priv->psstatus.status) ==
+ PS_SNOOZE) {
+ atomic_set(&priv->psstatus.status,
+ PS_WAKEUP);
+ priv->wakeup_count = 0;
}
+ complete(&priv->psstatus.wakeup_wait);
}
+ }
- do {
- /* read (WriteStatus/ReadDataSize FN1:00_0014) */
- retval =
- ks7010_sdio_read(priv, WSTATUS_RSIZE, &rw_data,
-sizeof(rw_data));
- if (retval) {
- DPRINTK(1, " error : WSTATUS_RSIZE=%02X\n",
- rw_data);
- goto intr_out;
- }
- DPRINTK(4, "WSTATUS_RSIZE=%02X\n", rw_data);
- rsize = rw_data & RSIZE_MASK;
- if (rsize) {/* Read schedul
Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data
On Fri, Mar 03, 2017 at 03:15:34PM -0600, Tom Lendacky wrote:
> On 3/3/2017 2:42 PM, Bjorn Helgaas wrote:
> >On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote:
> >>From: Tom Lendacky
> >>
> >>The use of ioremap will force the setup data to be mapped decrypted even
> >>though setup data is encrypted. Switch to using memremap which will be
> >>able to perform the proper mapping.
> >
> >How should callers decide whether to use ioremap() or memremap()?
> >
> >memremap() existed before SME and SEV, and this code is used even if
> >SME and SEV aren't supported, so the rationale for this change should
> >not need the decryption argument.
>
> When SME or SEV is active an ioremap() will remove the encryption bit
> from the pagetable entry when it is mapped. This allows MMIO, which
> doesn't support SME/SEV, to be performed successfully. So my take is
> that ioremap() should be used for MMIO and memremap() for pages in RAM.
OK, thanks. The commit message should say something like "this is
RAM, not MMIO, so we should map it with memremap(), not ioremap()".
That's the part that determines whether the change is correct.
You can mention the encryption part, too, but it's definitely
secondary because the change has to make sense on its own, without
SME/SEV.
The following commits (from https://github.com/codomania/tip/branches)
all do basically the same thing so the changelogs (and summaries)
should all be basically the same:
cb0d0d1eb0a6 x86: Change early_ioremap to early_memremap for BOOT data
91acb68b8333 x86/pci: Use memremap when walking setup data
4f687503e23f x86: Access the setup data through sysfs decrypted
e90246b8c229 x86: Access the setup data through debugfs decrypted
I would collect them all together and move them to the beginning of
your series, since they don't depend on anything else.
Also, change "x86/pci: " to "x86/PCI" so it matches the previous
convention.
> >>Signed-off-by: Tom Lendacky
Acked-by: Bjorn Helgaas
> >>---
> >> arch/x86/pci/common.c |4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> >>index a4fdfa7..0b06670 100644
> >>--- a/arch/x86/pci/common.c
> >>+++ b/arch/x86/pci/common.c
> >>@@ -691,7 +691,7 @@ int pcibios_add_device(struct pci_dev *dev)
> >>
> >>pa_data = boot_params.hdr.setup_data;
> >>while (pa_data) {
> >>- data = ioremap(pa_data, sizeof(*rom));
> >>+ data = memremap(pa_data, sizeof(*rom), MEMREMAP_WB);
> >
> >I can't quite connect the dots here. ioremap() on x86 would do
> >ioremap_nocache(). memremap(MEMREMAP_WB) would do arch_memremap_wb(),
> >which is ioremap_cache(). Is making a cacheable mapping the important
> >difference?
>
> The memremap(MEMREMAP_WB) will actually check to see if it can perform
> a __va(pa_data) in try_ram_remap() and then fallback to the
> arch_memremap_wb(). So it's actually the __va() vs the ioremap_cache()
> that is the difference.
>
> Thanks,
> Tom
>
> >
> >>if (!data)
> >>return -ENOMEM;
> >>
> >>@@ -710,7 +710,7 @@ int pcibios_add_device(struct pci_dev *dev)
> >>}
> >>}
> >>pa_data = data->next;
> >>- iounmap(data);
> >>+ memunmap(data);
> >>}
> >>set_dma_domain_ops(dev);
> >>set_dev_domain_options(dev);
> >>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v2 04/32] KVM: SVM: Add SEV feature definitions to KVM
On Thu, Mar 02, 2017 at 10:12:48AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Define a new KVM CPU feature for Secure Encrypted Virtualization (SEV).
> The kernel will check for the presence of this feature to determine if
> it is running with SEV active.
>
> Define the SEV enable bit for the VMCB control structure. The hypervisor
> will use this bit to enable SEV in the guest.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/svm.h |1 +
> arch/x86/include/uapi/asm/kvm_para.h |1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index 2aca535..fba2a7b 100644
> --- a/arch/x86/include/asm/svm.h
> +++ b/arch/x86/include/asm/svm.h
> @@ -137,6 +137,7 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
> #define SVM_VM_CR_SVM_DIS_MASK 0x0010ULL
>
> #define SVM_NESTED_CTL_NP_ENABLE BIT(0)
> +#define SVM_NESTED_CTL_SEV_ENABLEBIT(1)
>
> struct __attribute__ ((__packed__)) vmcb_seg {
> u16 selector;
> diff --git a/arch/x86/include/uapi/asm/kvm_para.h
> b/arch/x86/include/uapi/asm/kvm_para.h
> index 1421a65..bc2802f 100644
> --- a/arch/x86/include/uapi/asm/kvm_para.h
> +++ b/arch/x86/include/uapi/asm/kvm_para.h
> @@ -24,6 +24,7 @@
> #define KVM_FEATURE_STEAL_TIME 5
> #define KVM_FEATURE_PV_EOI 6
> #define KVM_FEATURE_PV_UNHALT7
> +#define KVM_FEATURE_SEV 8
This looks like it needs documenting in Documentation/virtual/kvm/cpuid.txt
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: cb_pcidas64: move loop invariant
Loop invariant is inside the loop so code checks invariant on each
iteration of the loop. Invariant can be moved outside of the loop so
it is only checked once.
Move loop invariant outside of for loop.
Signed-off-by: Tobin C. Harding
---
drivers/staging/comedi/drivers/cb_pcidas64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c
b/drivers/staging/comedi/drivers/cb_pcidas64.c
index 3b98193..dff0648 100644
--- a/drivers/staging/comedi/drivers/cb_pcidas64.c
+++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
@@ -1496,8 +1496,8 @@ static int alloc_and_init_dma_members(struct
comedi_device *dev)
if (!devpriv->ai_buffer[i])
return -ENOMEM;
}
- for (i = 0; i < AO_DMA_RING_COUNT; i++) {
- if (ao_cmd_is_supported(board)) {
+ if (ao_cmd_is_supported(board)) {
+ for (i = 0; i < AO_DMA_RING_COUNT; i++) {
devpriv->ao_buffer[i] =
dma_alloc_coherent(&pcidev->dev,
DMA_BUFFER_SIZE,
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: comedi: cb_pcidas64: refactor relocated code
On Tue, Feb 28, 2017 at 02:36:25PM +, Ian Abbott wrote:
> On 27/02/17 21:08, Tobin C. Harding wrote:
> >Code was moved to a separate function in a previous patch. Code
> >structure wast maintained to ease review. Code may now be refactored
> >to ease reading.
> >
> >Move multi-line dereference onto single line. Give function parameter
> >more meaningful name. Fix minor alignment issue.
> >
> >Signed-off-by: Tobin C. Harding
> >---
> > drivers/staging/comedi/drivers/cb_pcidas64.c | 13 ++---
> > 1 file changed, 6 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c
> >b/drivers/staging/comedi/drivers/cb_pcidas64.c
> >index 385f007..16d2491 100644
> >--- a/drivers/staging/comedi/drivers/cb_pcidas64.c
> >+++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
> >@@ -1480,18 +1480,17 @@ static void init_stc_registers(struct comedi_device
> >*dev)
> > disable_ai_pacing(dev);
> > };
> >
> >-static int alloc_dma_member(int i, struct comedi_device *dev)
> >+static int alloc_dma_member(int member, struct comedi_device *dev)
> > {
> > struct pci_dev *pcidev = comedi_to_pci_dev(dev);
> > struct pcidas64_private *devpriv = dev->private;
> >
> >-devpriv->ao_buffer[i] =
> >+devpriv->ao_buffer[member] =
> > dma_alloc_coherent(&pcidev->dev,
> >-DMA_BUFFER_SIZE,
> >-&devpriv->
> >-ao_buffer_bus_addr[i],
> >-GFP_KERNEL);
> >-if (!devpriv->ao_buffer[i])
> >+ DMA_BUFFER_SIZE,
> >+ &devpriv->ao_buffer_bus_addr[member],
> >+ GFP_KERNEL);
> >+if (!devpriv->ao_buffer[member])
> > return -ENOMEM;
> > return 0;
> > }
> >
>
> This could be merged with the other patch. Also, the parameter 'member' is
> an index into the list of buffers, so you could call it 'index' or 'bufidx'
> or something.
When I went to redo this patch I noticed a better, more simple fix. It
does not remove the initial checkpatch warning but it's a fix none the
less. I have sent the patch with subject;
[PATCH] staging: comedi: cb_pcidas64: move loop invariant
This email is just to link the work and give you some reference.
thanks,
Tobin.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [lustre-devel] [PATCH] staging: lustre: fix sparse warning about different address spaces
On Mar 1, 2017, at 6:57 PM, Mario Bambagini wrote: > fixed the following sparse warning by adding proper cast: > drivers/staging//lustre/lustre/obdclass/obd_config.c:1055:74: warning: > incorrect type in argument 2 (different address spaces) > drivers/staging//lustre/lustre/obdclass/obd_config.c:1055:74:expected > char const [noderef] * > drivers/staging//lustre/lustre/obdclass/obd_config.c:1055:74:got char > *[assigned] sval > > Signed-off-by: Mario Bambagini The patch is fine, but just be advised this whole function is going away real soon now per Al Viro request (and also because it no longer does what it should). > --- > drivers/staging/lustre/lustre/obdclass/obd_config.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/staging/lustre/lustre/obdclass/obd_config.c > b/drivers/staging/lustre/lustre/obdclass/obd_config.c > index 9ca84c7..8fce88f 100644 > --- a/drivers/staging/lustre/lustre/obdclass/obd_config.c > +++ b/drivers/staging/lustre/lustre/obdclass/obd_config.c > @@ -1052,7 +1052,8 @@ int class_process_proc_param(char *prefix, struct > lprocfs_vars *lvars, > > oldfs = get_fs(); > set_fs(KERNEL_DS); > - rc = var->fops->write(&fakefile, sval, > + rc = var->fops->write(&fakefile, > + (const char __user *)sval, > vallen, NULL); > set_fs(oldfs); > } > -- > 2.1.4 > > ___ > lustre-devel mailing list > lustre-de...@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vc04_services: open brace code style fix
On Sun, Mar 05, 2017 at 04:24:43PM +1100, Sergiy Redko wrote: > This fixes an error found by checkpatch about the open > brace not being on the same line as if statement. > It also adds a missing blank like to fix another > checkpatch warning. > > Signed-off-by: Sergiy Redko > --- > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) This does not apply to my tree due to changes others have made to the driver already :( sorry, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging: dgnc: audit goto's in dgnc_driver
TODO file requests fix up of error handling.
Audit dgnc_driver.c and fix all return paths to be uniform and inline
with kernel coding style.
Signed-off-by: Tobin C. Harding
---
drivers/staging/dgnc/dgnc_driver.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 5381dbd..8075fff 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -98,13 +98,11 @@ static const struct board_id dgnc_ids[] = {
static int dgnc_do_remap(struct dgnc_board *brd)
{
- int rc = 0;
-
brd->re_map_membase = ioremap(brd->membase, 0x1000);
if (!brd->re_map_membase)
- rc = -ENOMEM;
+ return -ENOMEM;
- return rc;
+ return 0;
}
/*
@@ -198,7 +196,6 @@ static struct dgnc_board *dgnc_found_board(struct pci_dev
*pdev, int id)
brd->bd_dividend = 921600;
rc = dgnc_do_remap(brd);
-
if (rc < 0)
goto failed;
@@ -283,27 +280,23 @@ static struct dgnc_board *dgnc_found_board(struct pci_dev
*pdev, int id)
failed:
kfree(brd);
-
return ERR_PTR(rc);
}
static int dgnc_request_irq(struct dgnc_board *brd)
{
- int rc = 0;
-
if (brd->irq) {
- rc = request_irq(brd->irq, brd->bd_ops->intr,
+ int rc = request_irq(brd->irq, brd->bd_ops->intr,
IRQF_SHARED, "DGNC", brd);
-
if (rc) {
- dev_err(&brd->pdev->dev,
- "Failed to hook IRQ %d\n", brd->irq);
+ dev_err(&brd->pdev->dev, "Failed to hook IRQ %d\n",
+ brd->irq);
brd->state = BOARD_FAILED;
brd->dpastatus = BD_NOFEP;
- rc = -ENODEV;
+ return -ENODEV;
}
}
- return rc;
+ return 0;
}
static void dgnc_free_irq(struct dgnc_board *brd)
@@ -387,7 +380,6 @@ static int dgnc_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
/* wake up and enable device */
rc = pci_enable_device(pdev);
-
if (rc)
return -EIO;
@@ -419,17 +411,14 @@ static int dgnc_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
brd->dpastatus = BD_RUNNING;
dgnc_board[dgnc_num_boards++] = brd;
-
return 0;
free_irq:
dgnc_free_irq(brd);
unregister_tty:
dgnc_tty_unregister(brd);
-
failed:
kfree(brd);
-
return rc;
}
@@ -488,7 +477,6 @@ static int dgnc_start(void)
spin_unlock_irqrestore(&dgnc_poll_lock, flags);
add_timer(&dgnc_poll_timer);
-
return 0;
failed_device:
@@ -597,7 +585,6 @@ static int __init dgnc_init_module(void)
/* Initialize global stuff */
rc = dgnc_start();
-
if (rc < 0)
return rc;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] staging: dgnc: remove goto task from TODO list
TODO file contains task to verify and correct function return sites. Need to check for and implement correct usage of goto's when there is work to be done before returning. Patch series is broken up by file to ease review. Perhaps a single patch would have been more appropriate. Changes to dgnc_mgmt are more stylistic than all other changes. Perhaps if review ok's those changes patch set could be rolled into one patch. Happy to do so if deemed appropriate. In order to make all return sites uniform the following format was chosen 1. Use variable name 'rc' throughout. 2. No space after function call when checking return value rc = fn(foo); if (rc) return rc; 3. If multiple returns occur at start of function with same error code, define and declare rc in single statement and return rc int rc = -ENOMEM; ... if (conditional) return rc; ... if (other-conditional) return rc; ... Tobin C. Harding (4): staging: dgnc: audit goto's in dgnc_driver staging: dgnc: audit goto's in dgnc_mgmt staging: dgnc: audit goto's in dgnc_tty staging: dgnc: remove item from TODO list drivers/staging/dgnc/TODO | 1 - drivers/staging/dgnc/dgnc_driver.c | 27 ++--- drivers/staging/dgnc/dgnc_mgmt.c | 37 --- drivers/staging/dgnc/dgnc_tty.c| 219 +++-- 4 files changed, 139 insertions(+), 145 deletions(-) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging: dgnc: audit goto's in dgnc_tty
TODO file requests fix up of error handling.
Audit dgnc_mgmt.c and fix all return paths to be uniform and inline
with kernel coding style.
Signed-off-by: Tobin C. Harding
---
drivers/staging/dgnc/dgnc_tty.c | 219
1 file changed, 112 insertions(+), 107 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index c3b8fc5..4398ace 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -143,7 +143,6 @@ int dgnc_tty_register(struct dgnc_board *brd)
TTY_DRIVER_REAL_RAW |
TTY_DRIVER_DYNAMIC_DEV |
TTY_DRIVER_HARDWARE_BREAK);
-
if (IS_ERR(brd->serial_driver))
return PTR_ERR(brd->serial_driver);
@@ -181,7 +180,6 @@ int dgnc_tty_register(struct dgnc_board *brd)
TTY_DRIVER_REAL_RAW |
TTY_DRIVER_DYNAMIC_DEV |
TTY_DRIVER_HARDWARE_BREAK);
-
if (IS_ERR(brd->print_driver)) {
rc = PTR_ERR(brd->print_driver);
goto unregister_serial_driver;
@@ -220,7 +218,6 @@ int dgnc_tty_register(struct dgnc_board *brd)
tty_unregister_driver(brd->serial_driver);
free_serial_driver:
put_tty_driver(brd->serial_driver);
-
return rc;
}
@@ -241,6 +238,7 @@ void dgnc_tty_unregister(struct dgnc_board *brd)
int dgnc_tty_init(struct dgnc_board *brd)
{
int i;
+ int rc;
void __iomem *vaddr;
struct channel_t *ch;
@@ -260,8 +258,10 @@ int dgnc_tty_init(struct dgnc_board *brd)
*/
brd->channels[i] = kzalloc(sizeof(*brd->channels[i]),
GFP_KERNEL);
- if (!brd->channels[i])
+ if (!brd->channels[i]) {
+ rc = -ENOMEM;
goto err_free_channels;
+ }
}
ch = brd->channels[0];
@@ -319,7 +319,7 @@ int dgnc_tty_init(struct dgnc_board *brd)
kfree(brd->channels[i]);
brd->channels[i] = NULL;
}
- return -ENOMEM;
+ return rc;
}
/*
@@ -914,7 +914,6 @@ static int dgnc_tty_open(struct tty_struct *tty, struct
file *file)
*/
rc = wait_event_interruptible(brd->state_wait,
(brd->state & BOARD_READY));
-
if (rc)
return rc;
@@ -922,14 +921,14 @@ static int dgnc_tty_open(struct tty_struct *tty, struct
file *file)
/* If opened device is greater than our number of ports, bail. */
if (PORT_NUM(minor) >= brd->nasync) {
- spin_unlock_irqrestore(&brd->bd_lock, flags);
- return -ENXIO;
+ rc = -ENXIO;
+ goto err_brd_unlock;
}
ch = brd->channels[PORT_NUM(minor)];
if (!ch) {
- spin_unlock_irqrestore(&brd->bd_lock, flags);
- return -ENXIO;
+ rc = -ENXIO;
+ goto err_brd_unlock;
}
/* Drop board lock */
@@ -946,8 +945,8 @@ static int dgnc_tty_open(struct tty_struct *tty, struct
file *file)
un = &brd->channels[PORT_NUM(minor)]->ch_pun;
un->un_type = DGNC_PRINT;
} else {
- spin_unlock_irqrestore(&ch->ch_lock, flags);
- return -ENXIO;
+ rc = -ENXIO;
+ goto err_ch_unlock;
}
/*
@@ -959,7 +958,6 @@ static int dgnc_tty_open(struct tty_struct *tty, struct
file *file)
rc = wait_event_interruptible(ch->ch_flags_wait,
((ch->ch_flags & CH_OPENING) == 0));
-
/* If ret is non-zero, user ctrl-c'ed us */
if (rc)
return -EINTR;
@@ -975,7 +973,6 @@ static int dgnc_tty_open(struct tty_struct *tty, struct
file *file)
ch->ch_flags_wait,
(((ch->ch_tun.un_flags |
ch->ch_pun.un_flags) & UN_CLOSING) == 0));
-
/* If ret is non-zero, user ctrl-c'ed us */
if (rc)
return -EINTR;
@@ -1014,7 +1011,6 @@ static int dgnc_tty_open(struct tty_struct *tty, struct
file *file)
kfree(ch->ch_rqueue);
kfree(ch->ch_equeue);
kfree(ch->ch_wqueue);
-
return -ENOMEM;
}
@@ -1082,6 +1078,14 @@ static int dgnc_tty_open(struct tty_struct *tty, struct
file *file)
spin_unlock_irqrestore(&ch->ch_lock, flags);
return rc;
+
+err_brd_unlock:
+ spin_unlock_irqrestore(&brd->bd_lock, flags);
+ return rc;
+err_ch_unlock:
+ spin_unlock_irqrestore(&ch->ch_lock, flags);
+ return rc;
+
}
/*
@@ -1093,7 +1097,7 @@ static int dgnc_blo
[PATCH 2/4] staging: dgnc: audit goto's in dgnc_mgmt
TODO file requests fix up of error handling.
Audit dgnc_mgmt.c and fix all return paths to be uniform and inline
with kernel coding style.
Signed-off-by: Tobin C. Harding
---
drivers/staging/dgnc/dgnc_mgmt.c | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_mgmt.c b/drivers/staging/dgnc/dgnc_mgmt.c
index 9d9b15d..9e984eb 100644
--- a/drivers/staging/dgnc/dgnc_mgmt.c
+++ b/drivers/staging/dgnc/dgnc_mgmt.c
@@ -42,25 +42,25 @@ int dgnc_mgmt_open(struct inode *inode, struct file *file)
{
unsigned long flags;
unsigned int minor = iminor(inode);
+ int rc = 0;
spin_lock_irqsave(&dgnc_global_lock, flags);
/* mgmt device */
- if (minor < MAXMGMTDEVICES) {
- /* Only allow 1 open at a time on mgmt device */
- if (dgnc_mgmt_in_use[minor]) {
- spin_unlock_irqrestore(&dgnc_global_lock, flags);
- return -EBUSY;
- }
- dgnc_mgmt_in_use[minor]++;
- } else {
- spin_unlock_irqrestore(&dgnc_global_lock, flags);
- return -ENXIO;
+ if (minor >= MAXMGMTDEVICES) {
+ rc = -ENXIO;
+ goto out;
}
+ /* Only allow 1 open at a time on mgmt device */
+ if (dgnc_mgmt_in_use[minor]) {
+ rc = -EBUSY;
+ goto out;
+ }
+ dgnc_mgmt_in_use[minor]++;
+out:
spin_unlock_irqrestore(&dgnc_global_lock, flags);
-
- return 0;
+ return rc;
}
/*
@@ -72,17 +72,20 @@ int dgnc_mgmt_close(struct inode *inode, struct file *file)
{
unsigned long flags;
unsigned int minor = iminor(inode);
+ int rc = 0;
spin_lock_irqsave(&dgnc_global_lock, flags);
/* mgmt device */
- if (minor < MAXMGMTDEVICES) {
- if (dgnc_mgmt_in_use[minor])
- dgnc_mgmt_in_use[minor] = 0;
+ if (minor >= MAXMGMTDEVICES) {
+ rc = -ENXIO;
+ goto out;
}
- spin_unlock_irqrestore(&dgnc_global_lock, flags);
+ dgnc_mgmt_in_use[minor] = 0;
- return 0;
+out:
+ spin_unlock_irqrestore(&dgnc_global_lock, flags);
+ return rc;
}
/*
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging: dgnc: remove item from TODO list
TODO file contains task to verify and correct function return sites. Need to check for and implement correct usage of goto's when there is work to be done before returning. Remove task from TODO list after already having completed audit of directory drivers/staging/dgnc. Signed-off-by: Tobin C. Harding --- drivers/staging/dgnc/TODO | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/dgnc/TODO b/drivers/staging/dgnc/TODO index e26d1d6..d3806be 100644 --- a/drivers/staging/dgnc/TODO +++ b/drivers/staging/dgnc/TODO @@ -1,7 +1,6 @@ * remove unnecessary comments * remove unnecessary error messages. Example kzalloc() has its own error message. Adding an extra one is useless. -* use goto statements for error handling when appropriate * there is a lot of unnecessary code in the driver. It was originally a standalone driver. Remove unneeded code. -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192e: fix coding style issue, improve error handling
Fix coding style issue and comments in rtl_core.c
Return -ENOMEM, if it is out of memory
Pointer comparison with NULL replaced by logical NOT
Signed-off-by: Suniel Mahesh
---
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 253 +++
1 file changed, 100 insertions(+), 153 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 4c0caa6..1099c94 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1,4 +1,4 @@
-/**
+/
* Copyright(c) 2008 - 2010 Realtek Corporation. All rights reserved.
*
* Based on the r8180 driver, which is:
@@ -17,7 +17,7 @@
*
* Contact Information:
* wlanfae
-**/
+ */
#include
#include
#include
@@ -37,7 +37,6 @@
static int channels = 0x3fff;
static char *ifname = "wlan%d";
-
static const struct rtl819x_ops rtl819xp_ops = {
.nic_type = NIC_8192E,
.get_eeprom_size= rtl92e_get_eeprom_size,
@@ -100,9 +99,7 @@ static void _rtl92e_hard_data_xmit(struct sk_buff *skb,
struct net_device *dev,
static int _rtl92e_down(struct net_device *dev, bool shutdownrf);
static void _rtl92e_restart(void *data);
-/
- -IO STUFF-
-*/
+/* IO STUFF */
u8 rtl92e_readb(struct net_device *dev, int x)
{
@@ -140,9 +137,7 @@ void rtl92e_writew(struct net_device *dev, int x, u16 y)
udelay(20);
}
-/
- -GENERAL FUNCTION-
-*/
+/* GENERAL FUNCTION */
bool rtl92e_set_rf_state(struct net_device *dev,
enum rt_rf_power_state StateToSet,
RT_RF_CHANGE_SOURCE ChangeSource)
@@ -200,7 +195,6 @@ bool rtl92e_set_rf_state(struct net_device *dev,
priv->rtllib->RfOffReason = 0;
bActionAllowed = true;
-
if (rtState == eRfOff &&
ChangeSource >= RF_CHANGE_BY_HW)
bConnectBySSID = true;
@@ -223,7 +217,8 @@ bool rtl92e_set_rf_state(struct net_device *dev,
else
priv->blinked_ingpio = false;
rtllib_MgntDisconnect(priv->rtllib,
-
WLAN_REASON_DISASSOC_STA_HAS_LEFT);
+ WLAN_REASON_DISASSOC_STA_
+ HAS_LEFT);
}
}
if ((ChangeSource == RF_CHANGE_BY_HW) && !priv->bHwRadioOff)
@@ -247,7 +242,6 @@ bool rtl92e_set_rf_state(struct net_device *dev,
StateToSet, priv->rtllib->RfOffReason);
PHY_SetRFPowerState(dev, StateToSet);
if (StateToSet == eRfOn) {
-
if (bConnectBySSID && priv->blinked_ingpio) {
schedule_delayed_work(
&ieee->associate_procedure_wq, 0);
@@ -346,16 +340,16 @@ static void _rtl92e_update_cap(struct net_device *dev,
u16 cap)
}
}
- if (net->mode & (IEEE_G|IEEE_N_24G)) {
+ if (net->mode & (IEEE_G | IEEE_N_24G)) {
u8 slot_time_val;
u8 CurSlotTime = priv->slot_time;
if ((cap & WLAN_CAPABILITY_SHORT_SLOT_TIME) &&
- (!priv->rtllib->pHTInfo->bCurrentRT2RTLongSlotTime)) {
+ (!priv->rtllib->pHTInfo->bCurrentRT2RTLongSlotTime)) {
if (CurSlotTime != SHORT_SLOT_TIME) {
slot_time_val = SHORT_SLOT_TIME;
priv->rtllib->SetHwRegHandler(dev,
-HW_VAR_SLOT_TIME, &slot_time_val);
+ HW_VAR_SLOT_TIME, &slot_time_val);
}
} else {
if (CurSlotTime != NON_SHORT_SLOT_TIME) {
@@ -407,7 +401,6 @@ static void _rtl92e_qos_activate(void *data)
for (i = 0; i < QOS_QUEUE_NUM; i++)
priv->rtllib->SetHwRegHandler(dev, HW_VAR_AC_PARAM, (u8 *)(&i));
-
success:
mutex_unlock(&priv->mutex);
}
@@ -427,16 +420,1
RE: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
> On 03/06/2017 03:21 PM, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > The subject is wrong, should be something like "scsi: libfc convert > fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390. Very sorry about this: the error in the subject got from the time when I was trying to break the bigger drivers patch set into per-variable part and trying to automate the process too much :( I will fix it in the end version! Best Regards, Elena > > Other than that > Acked-by: Johannes Thumshirn > > -- > Johannes Thumshirn Storage > jthumsh...@suse.de+49 911 74053 689 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) > Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t
> Hello.
>
> On 03/06/2017 05:20 PM, Elena Reshetova wrote:
>
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova
> > Signed-off-by: Hans Liljestrand
> > Signed-off-by: Kees Cook
> > Signed-off-by: David Windsor
> [...]
> > diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
> > index 115414c..16c1313 100644
> > --- a/drivers/media/pci/cx88/cx88.h
> > +++ b/drivers/media/pci/cx88/cx88.h
> > @@ -24,6 +24,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -339,7 +340,7 @@ struct cx8802_dev;
> >
> > struct cx88_core {
> > struct list_head devlist;
> > - atomic_t refcount;
> > + refcount_t refcount;
>
> Could you please keep the name aligned with above and below?
You mean "not aligned" to devlist, but with a shift like it was before?
Sure, will fix. Is the patch ok otherwise?
Best Regards,
Elena.
>
> >
> > /* board name */
> > intnr;
> >
>
> MBR, Sergei
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
