summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* media: docs: split development info from cx88.rstMauro Carvalho Chehab2020-04-143-107/+114
| | | | | | | This file contains both admin and development stuff. Split on two, as they're usually read by different audiences. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: docs: split development info from bttv.rstMauro Carvalho Chehab2020-04-143-120/+124
| | | | | | | This file contains both admin and development stuff. Split on two, as they're usually read by different audiences. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: docs: split vimc.rst into devel and admin partsMauro Carvalho Chehab2020-04-143-11/+17
| | | | | | | The vimc driver has some kerneldoc markups, plus admin info. Split it into two files. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: docs: split meye.rst into admin and uAPI docsMauro Carvalho Chehab2020-04-143-41/+54
| | | | | | | Instead of placing both info from admin PoV and uAPI at the same place, split into two separate documents. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: docs: split ci.rst into uAPI and user guide docsMauro Carvalho Chehab2020-04-143-157/+161
| | | | | | | | | | | The ci.rst file contains two parts: the first one describing how to use the CA high level interface; the second one with uAPI internals. Split this on two separate files, adding the uAPI bits to the DVB ca.rst configuration. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: docs: split cpia2.rst on two filesMauro Carvalho Chehab2020-04-143-46/+58
| | | | | | | | In order to be able to better organize the subsystem, split the cpia2 information on two files: one user-facing and another one from Kernel development PoV. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: docs: move soc-camera.rst to stagingMauro Carvalho Chehab2020-04-142-1/+0
| | | | | | | As the entire soc_camera driver is on staging to be removed soon, let's place there its documentation too. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: docs: avermedia.rst: mark a table as suchMauro Carvalho Chehab2020-04-141-0/+4
| | | | | | | There's a table on this file, with aren't using the ReST markups. Fix that. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: don't use visible for device type selectMauro Carvalho Chehab2020-04-141-9/+16
| | | | | | | | | | | While making the menu invisible seemed a good idea, there's a drawback: when the menu is not visible, it is not parsing the "default" dependency. So, instead, let's just avoid the items at the menu to be prompted, by using the "prompt ... if" construction. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: i2c/Kconfig: reorganize items thereMauro Carvalho Chehab2020-04-141-110/+106
| | | | | | | | | | | | Right now, there are I2C drivers that don't depend on camera support before and after those. Move the camera support drivers to the end, and add a notice at the "endif", in order to make easier to maintain and to avoid adding extra dependencies at the other i2c/*/Kconfig files. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: Better organize the per-API optionsMauro Carvalho Chehab2020-04-141-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After this change, the menu is displayed like above. 1) When filtering is not active: --- Multimedia support [ ] Filter devices by their types [*] Autoselect ancillary drivers (tuners, sensors, i2c, spi, frontends) Media core support ---> Video4Linux options ---> Media controller options ---> Digital TV options ---> HDMI CEC options ---> Media drivers ---> 2) When filtering is active: --- Multimedia support [*] Filter devices by their types [*] Autoselect ancillary drivers (tuners, sensors, i2c, spi, frontends) Media device types ---> Video4Linux options ---> Media controller options ---> Digital TV options ---> HDMI CEC options ---> Media drivers ---> The per-API menu will only be displayed if the corresponding core support is enabled. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: on !EMBEDDED && !EXPERT, enable driver filteringMauro Carvalho Chehab2020-04-141-0/+1
| | | | | | | | | | | | Advanced and embedded users know what to do, so, by default, they will likely want to be able to open the entire set of Kconfig media options. Normal "poor" users usually needs more help when setting stuff, so let's open an more simplified version to them by default. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: move the position of sub-driver autoselectionMauro Carvalho Chehab2020-04-141-25/+25
| | | | | | | | Let's place the sub-driver-autoselection option just below the device filtering one, as it also controls a filter menu, with is not even visible if !EXPERT && !EMBEDDED. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: place all options under a sub-menuMauro Carvalho Chehab2020-04-141-10/+18
| | | | | | | | That should make easier for people setting the media subsystem config options, as they'll be split by the type of functionality that will be enabled. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: move media controller core select to main KconfigMauro Carvalho Chehab2020-04-142-9/+9
| | | | | | | Let's place the main API selections at the media/Kconfig file, as this way we can better organize things. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: move V4L2 subdev API to v4l2-core/KconfigMauro Carvalho Chehab2020-04-142-9/+9
| | | | | | | | This option is part of V4L2 API extra functionality set. Move it to be at the v4l2-core/Kconfig, where it belongs, cleaning the main Kconfig file. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: move DVB-specific options to dvb-core/KconfigMauro Carvalho Chehab2020-04-142-21/+26
| | | | | | | In order to cleanup the main media Kconfig, move the DVB-core specific options to dvb-core/Kconfig. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: move CEC-specific options to cec/KconfigMauro Carvalho Chehab2020-04-142-9/+10
| | | | | | | | | | There's no need to have the CEC definitions inside the media Kconfig, as the Kconfig parser doesn't require symbols to be declared before their usages. With that, the main Kconfig menu becomes cleaner. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: warn if drivers are filteredMauro Carvalho Chehab2020-04-141-1/+4
| | | | | | | | As per a tester feedback, add an option to report when the drivers are filtered at the Kconfig menu. Cc: Helen Koike <helen.koike@collabora.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: make filtering devices optionalMauro Carvalho Chehab2020-04-141-4/+27
| | | | | | | | | The per-device option selection is a feature that some developers love, while others hate... So, let's make both happy by making it optional. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: use a sub-menu to select supported devicesMauro Carvalho Chehab2020-04-141-11/+14
| | | | | | | | | | | | The media subsystem has hundreds of driver-specific options. The *_SUPPORT config options work as a sort of filter, allowing to reduce its complexity for users that won't want to dig into thousands of options they don't need. Yet, it the filtering options are becoming large. So, let's place it on a sub-menu. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: reorganize the drivers menu optionsMauro Carvalho Chehab2020-04-141-8/+7
| | | | | | | | | | The comments before some of the drivers support look weird, because their Kconfig have their own "comment" directive inside it. So, rearrange them to make it look a little nicer for the ones with are not too familiar with the media system. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig files: use select for V4L2 subdevs and MCMauro Carvalho Chehab2020-04-1425-106/+237
| | | | | | | | | | | | | | | | | | | | | There are lots of drivers that only work when the media controller and/or the V4L2 subdev APIs are present. Right now, someone need to first enable those APIs before using those drivers. Well, ideally, drivers, should, instead *optionally* depend on it, in order for PC camera drivers to be able to use them, but nowadays most drivers are UVC cameras, with don't require a sensor driver. So, be it. Let's instead make them select the MEDIA_CONTROLLER and the SUBDEV API, in order to make easier for people to be able of enabling them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: dvb-core: Kconfig: default to use dynamic minorsMauro Carvalho Chehab2020-04-141-0/+1
| | | | | | | | | | | All modern Linux distributions nowadays use udev or some alternative (like systemd). So, it makes sense to change the default to use dynamic minors. Please notice that this default doesn't enable any code. It just changes the dvb-core behavior. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: add SPDX headers on Kconfig and Makefile filesMauro Carvalho Chehab2020-04-148-0/+16
| | | | | | | Most of media Kconfig/Makefile files already has SPDX, but there are a few ones still missing. Add it to them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: fix selection for test driversMauro Carvalho Chehab2020-04-144-9/+14
| | | | | | | | | | | | | | | | | | | There are some long-time mistakes related to build test drivers, with regards to depends on/select. Also, as we now want to build any test driver without needing to enable anything else, change the logic in order to properly filter them. Please notice that the PCI skeleton is somewhat an exception, as it requires to select *both* SAMPLES and MEDIA_TEST_SUPPORT. I almost changed it to be either one, but decided to keep it as-is, as this is something that we don't really need to be included on any distribution. The only reason for someone to build it is for COMPILE_TEST purposes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: better support hybrid TV devicesMauro Carvalho Chehab2020-04-1414-38/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now, if one has an hybrid TV card, it has to select both analog and digital TV support, as otherwise the needed core support won't be selected. Change the logic to auto-select the core support for those drivers, as this is a way more intuitive. It should be noticed that, as now both DVB_CORE and VIDEO_DEV defaults depends on selecting a hybrid cards, we had to remove the explicit dependencies there, in order to avoid circular dependencies. That requires some tricks: 1) the prompt should not be not visible when an hybrid card is selected, as the user shold not change it. 2) When a media hybrid device is selected, the modular option for DVB_CORE and VIDEO_DEV will follow the MEDIA_SUPPORT dependency, as we can't have a core built with "y" with a driver built as module. Note: while here, moved two pure V4L2 PCI drivers out of the "hybrid" part of config and consider pvrusb2 as an hybrid device. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: simplify some dependenciesMauro Carvalho Chehab2020-04-141-2/+0
| | | | | | | | | both DVB_CORE and VIDEO_DEV already depends on MEDIA_SUPPORT, as they're below an if block. So, remove this double dependency. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: mark other drivers as test driversMauro Carvalho Chehab2020-04-142-0/+5
| | | | | | | | | | | Neither the PCI skeleton nor the DVB dummy driver are real drivers. They're there just as an example for a driver writter. Distros should not enable those drivers. So, hide them if MEDIA_TEST_SUPPORT is not selected. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ddbridge: use the ddbridge's own dummy fe driverMauro Carvalho Chehab2020-04-145-157/+3
| | | | | | | | | Cleanup the ddbridge's dummy driver by removing the parts that aren't needed by ddbridge, adding it to the building system and changing the binding at the driver to use the newer function name. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ddbridge-dummy_fe: do some vars and function renamesMauro Carvalho Chehab2020-04-142-83/+83
| | | | | | | | | As the name of this driver is now ddbridge-dummy, do some renames internally. No functional changes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: ddbridge: copy the dvb_dummy_fe driver to ddbridgeMauro Carvalho Chehab2020-04-142-0/+322
| | | | | | | | As we'll be transforming the dvb-dummy-fe driver soon into a virtual driver, let's first copy the existing one to ddbridge as-is, as it is needed there. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: mode firewire comment to firewire/KconfigMauro Carvalho Chehab2020-04-142-3/+4
| | | | | | | This comment should only be visible if the DVB_FIREDTV config will show. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: move drivers-specific TTPCI_EEPROM Kconfig varMauro Carvalho Chehab2020-04-142-5/+6
| | | | | | | | | This option is used only by av7110 and by an USB driver. As the av7110 is the first DVB hardware, hardly found those days, let's opt to place it at usb/Kconfig, as the driver with needs it might have a longer lifetime. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: move comment to siano includeMauro Carvalho Chehab2020-04-142-1/+2
| | | | | | | | Showing this comment without showing the Siano mmc option is very weird! Place the option together, and make it visible only when showing Siano configuration. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: split test drivers from platform directoryMauro Carvalho Chehab2020-04-1468-28/+51
| | | | | | | | | | | | | | | | | | | | | When the first test device was added (vivi.c), there were just one file. I was too lazy on that time to create a separate directory just for it, so I kept it together with platform. Now, we have vivid, vicodec, vim2m and vimc. Also, a new virtual driver has been prepared to support DVB API. So, it is time to solve this mess, by placing test stuff on a separate directory. It should be noticed that we also have some skeleton drivers (for V4L and for DVB). For now, we'll keep them separate, as they're not really test drivers, but instead, just examples. The DVB frontend ones will likely be part of a new DVB test driver. By that time, it should make sense to move them here as well. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: update the MEDIA_SUPPORT help messageMauro Carvalho Chehab2020-04-141-2/+4
| | | | | | | There are more things than just cameras and TV devices on media. Update the help message accordingly. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: pci: move VIDEO_PCI_SKELETON to a different KconfigMauro Carvalho Chehab2020-04-142-10/+10
| | | | | | | | | The V4L2 PCI skeleton is not part of the V4L2 core. Move it to appear together with the other PCI drivers, at the end, as this is something that normal users don't even need to bother. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: not all V4L2 platform drivers are for cameraMauro Carvalho Chehab2020-04-142-5/+1
| | | | | | | | | | | When the platform drivers got added, they were all part of complex camera support. This is not the case anymore, as we now have codecs and other stuff there too. So, fix the dependencies, in order to not require users to manually select something that it doesn't make sense. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: Kconfig: add an option to filter in/out platform driversMauro Carvalho Chehab2020-04-141-5/+16
| | | | | | | | | Most systems don't need support for those, while others only need those, instead of the others. So, add an option to filter in/out platform drivers. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* media: dvb-usb: auto-select CYPRESS_FIRMWAREMauro Carvalho Chehab2020-04-142-1/+2
| | | | | | | | | | | | | At least some of the supported boards by dvb-usb driver need to load the cypress firmware, so select it, as otherwise missing dependencies may popup. Also, as the cypress firmware load routines are needed only by the dvb-usb, dvb-usb-v2 and go7007 drivers, and those all (now) select it, there's no need to ask the user for manually select it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
* Linux 5.7-rc1v5.7-rc1Linus Torvalds2020-04-121-2/+2
|
* MAINTAINERS: sort field names for all entriesLinus Torvalds2020-04-121-1974/+1974
| | | | | | | | | | | | | | | This sorts the actual field names too, potentially causing even more chaos and confusion at merge time if you have edited the MAINTAINERS file. But the end result is a more consistent layout, and hopefully it's a one-time pain minimized by doing this just before the -rc1 release. This was entirely scripted: ./scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS --order Requested-by: Joe Perches <joe@perches.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* MAINTAINERS: sort entries by entry nameLinus Torvalds2020-04-121-820/+820
| | | | | | | | | | | | | | | | | | | | | They are all supposed to be sorted, but people who add new entries don't always know the alphabet. Plus sometimes the entry names get edited, and people don't then re-order the entry. Let's see how painful this will be for merging purposes (the MAINTAINERS file is often edited in various different trees), but Joe claims there's relatively few patches in -next that touch this, and doing it just before -rc1 is likely the best time. Fingers crossed. This was scripted with /scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS but then I also ended up manually upper-casing a few entry names that stood out when looking at the end result. Requested-by: Joe Perches <joe@perches.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge tag 'x86-urgent-2020-04-12' of ↵Linus Torvalds2020-04-124-9/+79
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: "A set of three patches to fix the fallout of the newly added split lock detection feature. It addressed the case where a KVM guest triggers a split lock #AC and KVM reinjects it into the guest which is not prepared to handle it. Add proper sanity checks which prevent the unconditional injection into the guest and handles the #AC on the host side in the same way as user space detections are handled. Depending on the detection mode it either warns and disables detection for the task or kills the task if the mode is set to fatal" * tag 'x86-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: KVM: VMX: Extend VMXs #AC interceptor to handle split lock #AC in guest KVM: x86: Emulate split-lock access as a write in emulator x86/split_lock: Provide handle_guest_split_lock()
| * KVM: VMX: Extend VMXs #AC interceptor to handle split lock #AC in guestXiaoyao Li2020-04-111-3/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two types of #AC can be generated in Intel CPUs: 1. legacy alignment check #AC 2. split lock #AC Reflect #AC back into the guest if the guest has legacy alignment checks enabled or if split lock detection is disabled. If the #AC is not a legacy one and split lock detection is enabled, then invoke handle_guest_split_lock() which will either warn and disable split lock detection for this task or force SIGBUS on it. [ tglx: Switch it to handle_guest_split_lock() and rename the misnamed helper function. ] Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://lkml.kernel.org/r/20200410115517.176308876@linutronix.de
| * KVM: x86: Emulate split-lock access as a write in emulatorXiaoyao Li2020-04-111-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Emulate split-lock accesses as writes if split lock detection is on to avoid #AC during emulation, which will result in a panic(). This should never occur for a well-behaved guest, but a malicious guest can manipulate the TLB to trigger emulation of a locked instruction[1]. More discussion can be found at [2][3]. [1] https://lkml.kernel.org/r/8c5b11c9-58df-38e7-a514-dc12d687b198@redhat.com [2] https://lkml.kernel.org/r/20200131200134.GD18946@linux.intel.com [3] https://lkml.kernel.org/r/20200227001117.GX9940@linux.intel.com Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://lkml.kernel.org/r/20200410115517.084300242@linutronix.de
| * x86/split_lock: Provide handle_guest_split_lock()Thomas Gleixner2020-04-112-5/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without at least minimal handling for split lock detection induced #AC, VMX will just run into the same problem as the VMWare hypervisor, which was reported by Kenneth. It will inject the #AC blindly into the guest whether the guest is prepared or not. Provide a function for guest mode which acts depending on the host SLD mode. If mode == sld_warn, treat it like user space, i.e. emit a warning, disable SLD and mark the task accordingly. Otherwise force SIGBUS. [ bp: Add a !CPU_SUP_INTEL stub for handle_guest_split_lock(). ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://lkml.kernel.org/r/20200410115516.978037132@linutronix.de Link: https://lkml.kernel.org/r/20200402123258.895628824@linutronix.de
* | Merge tag 'timers-urgent-2020-04-12' of ↵Linus Torvalds2020-04-123-0/+10
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull time(keeping) updates from Thomas Gleixner: - Fix the time_for_children symlink in /proc/$PID/ so it properly reflects that it part of the 'time' namespace - Add the missing userns limit for the allowed number of time namespaces, which was half defined but the actual array member was not added. This went unnoticed as the array has an exessive empty member at the end but introduced a user visible regression as the output was corrupted. - Prevent further silent ucount corruption by adding a BUILD_BUG_ON() to catch half updated data. * tag 'timers-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: ucount: Make sure ucounts in /proc/sys/user don't regress again time/namespace: Add max_time_namespaces ucount time/namespace: Fix time_for_children symlink
| * | ucount: Make sure ucounts in /proc/sys/user don't regress againJan Kara2020-04-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 769071ac9f20 "ns: Introduce Time Namespace" broke reporting of inotify ucounts (max_inotify_instances, max_inotify_watches) in /proc/sys/user because it has added UCOUNT_TIME_NAMESPACES into enum ucount_type but didn't properly update reporting in kernel/ucount.c:setup_userns_sysctls(). This problem got fixed in commit eeec26d5da82 "time/namespace: Add max_time_namespaces ucount". Add BUILD_BUG_ON to catch a similar problem in the future. Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Andrei Vagin <avagin@gmail.com> Link: https://lkml.kernel.org/r/20200407154643.10102-1-jack@suse.cz