4.14.213-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 189/242 ALSA: pcm: oss: Fix a few more UBSAN fixes
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit 11cb881bf075cea41092a20236ba708b18e1dbb2 upstream.
There are a few places that call round{up|down}_pow_of_two() with the value zero, and this causes undefined behavior warnings. Avoid calling those macros if such a nonsense value is passed; it's a minor optimization as well, as we handle it as either an error or a value to be skipped, instead.
--- sound/core/oss/pcm_oss.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-)
sound/core/oss/pcm_oss.c +14 -8
@@ -708,6 +708,8 @@ static int snd_pcm_oss_period_size(struc oss_buffer_size =snd_pcm_plug_client_size (substream,snd_pcm_hw_param_value_max (slave_params,SNDRV_PCM_HW_PARAM_BUFFER_SIZE ,NULL )) * oss_frame_size; +if (!oss_buffer_size) +return -EINVAL ; oss_buffer_size =rounddown_pow_of_two (oss_buffer_size);if (atomic_read (&substream->mmap_count)) {if (oss_buffer_size > runtime->oss.mmap_bytes)
@@ -743,17 +745,21 @@ static int snd_pcm_oss_period_size(struc min_period_size =snd_pcm_plug_client_size (substream,snd_pcm_hw_param_value_min (slave_params,SNDRV_PCM_HW_PARAM_PERIOD_SIZE ,NULL )); - min_period_size *= oss_frame_size; - min_period_size =roundup_pow_of_two (min_period_size); -if (oss_period_size < min_period_size) - oss_period_size = min_period_size; +if (min_period_size) { + min_period_size *= oss_frame_size; + min_period_size =roundup_pow_of_two (min_period_size); +if (oss_period_size < min_period_size) + oss_period_size = min_period_size; + } max_period_size =snd_pcm_plug_client_size (substream,snd_pcm_hw_param_value_max (slave_params,SNDRV_PCM_HW_PARAM_PERIOD_SIZE ,NULL )); - max_period_size *= oss_frame_size; - max_period_size =rounddown_pow_of_two (max_period_size); -if (oss_period_size > max_period_size) - oss_period_size = max_period_size; +if (max_period_size) { + max_period_size *= oss_frame_size; + max_period_size =rounddown_pow_of_two (max_period_size); +if (oss_period_size > max_period_size) + oss_period_size = max_period_size; + } oss_periods = oss_buffer_size / oss_period_size;
Greg Kroah-Hartman
maintainerPATCH 190/242 ALSA: usb-audio: Disable sample read check if firmware doesnt give back
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit 9df28edce7c6ab38050235f6f8b43dd7ccd01b6d upstream.
Some buggy firmware don't give the current sample rate but leaves zero. Handle this case more gracefully without warning but just skip the current rate verification from the next time.
--- sound/usb/clock.c | 6 ++++++ 1 file changed, 6 insertions(+)
sound/usb/clock.c +6 -0
@@ -327,6 +327,12 @@ static int set_sample_rate_v1(struct snd } crate = data[0 ] | (data[1 ] <<8 ) | (data[2 ] <<16 ); +if (!crate) { +dev_info (&dev->dev,"failed to read current rate; disabling the check\n" ); + chip->sample_rate_read_error =3 ;/* three strikes, see above */ +return 0 ; + } +if (crate != rate) {dev_warn (&dev->dev,"current rate %d is different from the runtime rate %d\n" , crate, rate);// runtime->rate = crate;
Greg Kroah-Hartman
maintainerPATCH 191/242 s390/smp: perform initial CPU reset also for SMT siblings
In reply to Greg Kroah-HartmanFrom: Sven Schnelle <[email protected]>
commit b5e438ebd7e808d1d2435159ac4742e01a94b8da upstream.
Not resetting the SMT siblings might leave them in unpredictable state. One of the observed problems was that the CPU timer wasn't reset and therefore large system time values where accounted during CPU bringup.
--- arch/s390/kernel/smp.c | 18 +++--------------- 1 file changed, 3 insertions(+), 15 deletions(-)
arch/s390/kernel/smp.c +3 -15
@@ -864,24 +864,12 @@ static void smp_start_secondary(void *cp/* Upping and downing of CPUs */ int __cpu_up (unsigned int cpu,struct task_struct *tidle) { -struct pcpu *pcpu; -int base, i, rc; +struct pcpu *pcpu = pcpu_devices + cpu; +int rc; - pcpu = pcpu_devices + cpu;if (pcpu->state !=CPU_STATE_CONFIGURED )return -EIO ; - base =smp_get_base_cpu (cpu); -for (i =0 ; i <= smp_cpu_mtid; i++) { -if (base + i < nr_cpu_ids) -if (cpu_online (base + i)) -break ; - } -/* -* If this is the first CPU of the core to get online -* do an initial CPU reset. -*/ -if (i > smp_cpu_mtid && -pcpu_sigp_retry (pcpu_devices + base,SIGP_INITIAL_CPU_RESET ,0 ) != +if (pcpu_sigp_retry (pcpu,SIGP_INITIAL_CPU_RESET ,0 ) !=SIGP_CC_ORDER_CODE_ACCEPTED )return -EIO ;
Greg Kroah-Hartman
maintainerPATCH 192/242 s390/dasd: prevent inconsistent LCU device data
In reply to Greg Kroah-HartmanFrom: Stefan Haberland <[email protected]>
commit a29ea01653493b94ea12bb2b89d1564a265081b6 upstream.
Prevent _lcu_update from adding a device to a pavgroup if the LCU still requires an update. The data is not reliable any longer and in parallel devices might have been moved on the lists already.
This might lead to list corruptions or invalid PAV grouping. Only add devices to a pavgroup if the LCU is up to date. Additional steps are taken by the scheduled lcu update.
--- drivers/s390/block/dasd_alias.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/s390/block/dasd_alias.c +9 -0
@@ -503,6 +503,14 @@ static int _lcu_update(struct dasd_devicreturn rc;spin_lock_irqsave (&lcu->lock, flags); +/* +* there is another update needed skip the remaining handling +* the data might already be outdated +* but especially do not add the device to an LCU with pending +* update +*/ +if (lcu->flags &NEED_UAC_UPDATE ) + goto out; lcu->pav =NO_PAV ;for (i =0 ; i <MAX_DEVICES_PER_LCU ; ++i) {switch (lcu->uac->unit[i].ua_type) {
@@ -521,6 +529,7 @@ static int _lcu_update(struct dasd_devic alias_list) {_add_device_to_lcu (lcu, device, refdev); } +out:spin_unlock_irqrestore (&lcu->lock, flags);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 193/242 s390/dasd: fix list corruption of pavgroup group list
In reply to Greg Kroah-HartmanFrom: Stefan Haberland <[email protected]>
commit 0ede91f83aa335da1c3ec68eb0f9e228f269f6d8 upstream.
dasd_alias_add_device() moves devices to the active_devices list in case of a scheduled LCU update regardless if they have previously been in a pavgroup or not.
Example: device A and B are in the same pavgroup.
Device A has already been in a pavgroup and the private->pavgroup pointer is set and points to a valid pavgroup. While going through dasd_add_device it is moved from the pavgroup to the active_devices list.
In parallel device B might be removed from the same pavgroup in remove_device_from_lcu() which in turn checks if the group is empty and deletes it accordingly because device A has already been removed from there.
When now device A enters remove_device_from_lcu() it is tried to remove it from the pavgroup again because the pavgroup pointer is still set and again the empty group will be cleaned up which leads to a list corruption.
Fix by setting private->pavgroup to NULL in dasd_add_device.
If the device has been the last device on the pavgroup an empty pavgroup remains but this will be cleaned up by the scheduled lcu_update which iterates over all existing pavgroups.
--- drivers/s390/block/dasd_alias.c | 1 + 1 file changed, 1 insertion(+)
drivers/s390/block/dasd_alias.c +1 -0
@@ -634,6 +634,7 @@ int dasd_alias_add_device(struct dasd_de }if (lcu->flags &UPDATE_PENDING ) {list_move (&device->alias_list, &lcu->active_devices); + private->pavgroup =NULL ;_schedule_lcu_update (lcu, device); }spin_unlock_irqrestore (&lcu->lock, flags);
Greg Kroah-Hartman
maintainerPATCH 194/242 s390/dasd: fix list corruption of lcu list
In reply to Greg Kroah-HartmanFrom: Stefan Haberland <[email protected]>
commit 53a7f655834c7c335bf683f248208d4fbe4b47bc upstream.
In dasd_alias_disconnect_device_from_lcu the device is removed from any list on the LCU. Afterwards the LCU is removed from the lcu list if it does not contain devices any longer.
The lcu->lock protects the lcu from parallel updates. But to cancel all workers and wait for completion the lcu->lock has to be unlocked.
If two devices are removed in parallel and both are removed from the LCU the first device that takes the lcu->lock again will delete the LCU because it is already empty but the second device also tries to free the LCU which leads to a list corruption of the lcu list.
Fix by removing the device right before the lcu is checked without unlocking the lcu->lock in between.
--- drivers/s390/block/dasd_alias.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/s390/block/dasd_alias.c +1 -1
@@ -256,7 +256,6 @@ void dasd_alias_disconnect_device_from_lreturn ; device->discipline->get_uid (device, &uid);spin_lock_irqsave (&lcu->lock, flags); -list_del_init (&device->alias_list);/* make sure that the workers don't use this device */ if (device == lcu->suc_data.device) {spin_unlock_irqrestore (&lcu->lock, flags);
@@ -283,6 +282,7 @@ void dasd_alias_disconnect_device_from_lspin_lock_irqsave (&aliastree.lock, flags);spin_lock (&lcu->lock); +list_del_init (&device->alias_list);if (list_empty (&lcu->grouplist) &&list_empty (&lcu->active_devices) &&list_empty (&lcu->inactive_devices)) {
Greg Kroah-Hartman
maintainerPATCH 195/242 staging: comedi: mf6x4: Fix AI end-of-conversion detection
In reply to Greg Kroah-HartmanFrom: Ian Abbott <[email protected]>
commit 56c90457ebfe9422496aac6ef3d3f0f0ea8b2ec2 upstream.
I have had reports from two different people that attempts to read the analog input channels of the MF624 board fail with an ETIMEDOUT error.
After triggering the conversion, the code calls comedi_timeout() with mf6x4_ai_eoc() as the callback function to check if the conversion is complete. The callback returns 0 if complete or -EBUSY if not yet complete. comedi_timeout() returns -ETIMEDOUT if it has not completed within a timeout period which is propagated as an error to the user application.
The existing code considers the conversion to be complete when the EOLC bit is high. However, according to the user manuals for the MF624 and MF634 boards, this test is incorrect because EOLC is an active low signal that goes high when the conversion is triggered, and goes low when the conversion is complete. Fix the problem by inverting the test of the EOLC bit state.
--- drivers/staging/comedi/drivers/mf6x4.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/staging/comedi/drivers/mf6x4.c +2 -1
@@ -121,8 +121,9 @@ static int mf6x4_ai_eoc(struct comedi_destruct mf6x4_private *devpriv = dev->private;unsigned int status; +/* EOLC goes low at end of conversion. */ status =ioread32 (devpriv->gpioc_reg); -if (status &MF6X4_GPIOC_EOLC ) +if ((status &MF6X4_GPIOC_EOLC ) ==0 )return 0 ;return -EBUSY ; }
Greg Kroah-Hartman
maintainerPATCH 196/242 powerpc/perf: Exclude kernel samples while counting events in user space.
In reply to Greg Kroah-HartmanFrom: Athira Rajeev <[email protected]>
commit aa8e21c053d72b6639ea5a7f1d3a1d0209534c94 upstream.
Perf event attritube supports exclude_kernel flag to avoid sampling/profiling in supervisor state (kernel). Based on this event attr flag, Monitor Mode Control Register bit is set to freeze on supervisor state. But sometimes (due to hardware limitation), Sampled Instruction Address Register (SIAR) locks on to kernel address even when freeze on supervisor is set. Patch here adds a check to drop those samples.
--- arch/powerpc/perf/core-book3s.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/powerpc/perf/core-book3s.c +10 -0
@@ -2068,6 +2068,16 @@ static void record_and_restart(struct peperf_event_update_userpage (event);/* +* Due to hardware limitation, sometimes SIAR could sample a kernel +* address even when freeze on supervisor state (kernel) is set in +* MMCR2. Check attr.exclude_kernel and address to drop the sample in +* these cases. +*/ +if (event->attr.exclude_kernel && record) +if (is_kernel_addr (mfspr (SPRN_SIAR ))) + record =0 ; + +/* * Finally record data if requested. */ if (record) {
Greg Kroah-Hartman
maintainerPATCH 197/242 crypto: ecdh - avoid unaligned accesses in ecdh_set_secret()
In reply to Greg Kroah-HartmanFrom: Ard Biesheuvel <[email protected]>
commit 17858b140bf49961b71d4e73f1c3ea9bc8e7dda0 upstream.
ecdh_set_secret() casts a void* pointer to a const u64* in order to feed it into ecc_is_key_valid(). This is not generally permitted by the C standard, and leads to actual misalignment faults on ARMv6 cores. In some cases, these are fixed up in software, but this still leads to performance hits that are entirely avoidable.
So let's copy the key into the ctx buffer first, which we will do anyway in the common case, and which guarantees correct alignment.
--- crypto/ecdh.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
crypto/ecdh.c +5 -4
@@ -57,12 +57,13 @@ static int ecdh_set_secret(struct cryptoreturn ecc_gen_privkey (ctx->curve_id, ctx->ndigits, ctx->private_key); -if (ecc_is_key_valid (ctx->curve_id, ctx->ndigits, - (const u64 *)params.key, params.key_size) <0 ) -return -EINVAL ; -memcpy (ctx->private_key, params.key, params.key_size); +if (ecc_is_key_valid (ctx->curve_id, ctx->ndigits, + ctx->private_key, params.key_size) <0 ) { +memzero_explicit (ctx->private_key, params.key_size); +return -EINVAL ; + }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 198/242 EDAC/amd64: Fix PCI component registration
In reply to Greg Kroah-HartmanFrom: Borislav Petkov <[email protected]>
commit 706657b1febf446a9ba37dc51b89f46604f57ee9 upstream.
In order to setup its PCI component, the driver needs any node private instance in order to get a reference to the PCI device and hand that into edac_pci_create_generic_ctl(). For convenience, it uses the 0th memory controller descriptor under the assumption that if any, the 0th will be always present.
However, this assumption goes wrong when the 0th node doesn't have memory and the driver doesn't initialize an instance for it:
EDAC amd64: F17h detected (node 0).
...
EDAC amd64: Node 0: No DIMMs detected.
But looking up node instances is not really needed - all one needs is the pointer to the proper device which gets discovered during instance init.
So stash that pointer into a variable and use it when setting up the EDAC PCI component.
Clear that variable when the driver needs to unwind due to some instances failing init to avoid any registration imbalance.
--- drivers/edac/amd64_edac.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-)
drivers/edac/amd64_edac.c +14 -12
@@ -18,6 +18,9 @@ static struct msr __percpu *msrs;/* Per-node stuff */ static struct ecc_settings **ecc_stngs; +/* Device for the PCI component */ +static struct device *pci_ctl_dev; +/* * Valid scrub rates for the K8 hardware memory scrubber. We map the scrubbing * bandwidth to a valid bit pattern. The 'set' operation finds the 'matching-
@@ -2554,6 +2557,9 @@ reserve_mc_sibling_devs(struct amd64_pvtreturn -ENODEV ; } +if (!pci_ctl_dev) + pci_ctl_dev = &pvt->F0->dev; +edac_dbg (1 ,"F0: %s\n" ,pci_name (pvt->F0));edac_dbg (1 ,"F3: %s\n" ,pci_name (pvt->F3));edac_dbg (1 ,"F6: %s\n" ,pci_name (pvt->F6));
@@ -2578,6 +2584,9 @@ reserve_mc_sibling_devs(struct amd64_pvtreturn -ENODEV ; } +if (!pci_ctl_dev) + pci_ctl_dev = &pvt->F2->dev; +edac_dbg (1 ,"F1: %s\n" ,pci_name (pvt->F1));edac_dbg (1 ,"F2: %s\n" ,pci_name (pvt->F2));edac_dbg (1 ,"F3: %s\n" ,pci_name (pvt->F3));
@@ -3428,21 +3437,10 @@ static void remove_one_instance(unsignedstatic void setup_pci_device (void ) { -struct mem_ctl_info *mci; -struct amd64_pvt *pvt; -if (pci_ctl)return ; - mci =edac_mc_find (0 ); -if (!mci) -return ; - - pvt = mci->pvt_info; -if (pvt->umc) - pci_ctl =edac_pci_create_generic_ctl (&pvt->F0->dev,EDAC_MOD_STR ); -else - pci_ctl =edac_pci_create_generic_ctl (&pvt->F2->dev,EDAC_MOD_STR ); + pci_ctl =edac_pci_create_generic_ctl (pci_ctl_dev,EDAC_MOD_STR );if (!pci_ctl) {pr_warn ("%s(): Unable to create PCI control\n" , __func__);pr_warn ("%s(): PCI error report via EDAC not set\n" , __func__);
@@ -3517,6 +3515,8 @@ static int __init amd64_edac_init(void)return 0 ; err_pci: + pci_ctl_dev =NULL ; +msrs_free (msrs); msrs =NULL ;
@@ -3548,6 +3548,8 @@ static void __exit amd64_edac_exit(void)kfree (ecc_stngs); ecc_stngs =NULL ; + pci_ctl_dev =NULL ; +msrs_free (msrs); msrs =NULL ; }
Greg Kroah-Hartman
maintainerPATCH 199/242 USB: serial: mos7720: fix parallel-port state restore
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 975323ab8f116667676c30ca3502a6757bd89e8d upstream.
The parallel-port restore operations is called when a driver claims the port and is supposed to restore the provided state (e.g. saved when releasing the port).
--- drivers/usb/serial/mos7720.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/mos7720.c +2 -0
@@ -640,6 +640,8 @@ static void parport_mos7715_restore_statspin_unlock (&release_lock);return ; } + mos_parport->shadowDCR = s->u.pc.ctr; + mos_parport->shadowECR = s->u.pc.ecr;write_parport_reg_nonblock (mos_parport,MOS7720_DCR , mos_parport->shadowDCR); write_parport_reg_nonblock(mos_parport, MOS7720_ECR,
Greg Kroah-Hartman
maintainerPATCH 200/242 USB: serial: keyspan_pda: fix dropped unthrottle interrupts
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 696c541c8c6cfa05d65aa24ae2b9e720fc01766e upstream.
Commit c528fcb116e6 ("USB: serial: keyspan_pda: fix receive sanity checks") broke write-unthrottle handling by dropping well-formed unthrottle-interrupt packets which are precisely two bytes long. This could lead to blocked writers not being woken up when buffer space again becomes available.
Instead, stop unconditionally printing the third byte which is (presumably) only valid on modem-line changes.
--- drivers/usb/serial/keyspan_pda.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/serial/keyspan_pda.c +2 -2
@@ -176,11 +176,11 @@ static void keyspan_pda_rx_interrupt(strbreak ;case 1 :/* status interrupt */ -if (len <3 ) { +if (len <2 ) {dev_warn (&port->dev,"short interrupt message received\n" );break ; } -dev_dbg (&port->dev,"rx int, d1=%d, d2=%d\n" , data[1 ], data[2 ]); +dev_dbg (&port->dev,"rx int, d1=%d\n" , data[1 ]);switch (data[1 ]) {case 1 :/* modemline change */ break ;
Greg Kroah-Hartman
maintainerPATCH 201/242 USB: serial: keyspan_pda: fix write deadlock
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 7353cad7ee4deaefc16e94727e69285563e219f6 upstream.
The write() callback can be called in interrupt context (e.g. when used as a console) so interrupts must be disabled while holding the port lock to prevent a possible deadlock.
--- drivers/usb/serial/keyspan_pda.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/usb/serial/keyspan_pda.c +4 -3
@@ -447,6 +447,7 @@ static int keyspan_pda_write(struct tty_int request_unthrottle =0 ;int rc =0 ;struct keyspan_pda_private *priv; +unsigned long flags; priv =usb_get_serial_port_data (port);/* guess how much room is left in the device's ring buffer, and if we
@@ -466,13 +467,13 @@ static int keyspan_pda_write(struct tty_the TX urb is in-flight (wait until it completes) the device is full (wait until it says there is room) */ -spin_lock_bh (&port->lock); +spin_lock_irqsave (&port->lock, flags);if (!test_bit (0 , &port->write_urbs_free) || priv->tx_throttled) { -spin_unlock_bh (&port->lock); +spin_unlock_irqrestore (&port->lock, flags);return 0 ; }clear_bit (0 , &port->write_urbs_free); -spin_unlock_bh (&port->lock); +spin_unlock_irqrestore (&port->lock, flags);/* At this point the URB is in our control, nobody else can submit it again (the only sudden transition was the one from EINPROGRESS to
Greg Kroah-Hartman
maintainerPATCH 202/242 USB: serial: keyspan_pda: fix stalled writes
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit c01d2c58698f710c9e13ba3e2d296328606f74fd upstream.
Make sure to clear the write-busy flag also in case no new data was submitted due to lack of device buffer space so that writing is resumed once space again becomes available.
--- drivers/usb/serial/keyspan_pda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/serial/keyspan_pda.c +1 -1
@@ -552,7 +552,7 @@ static int keyspan_pda_write(struct tty_ rc = count; exit: -if (rc <0 ) +if (rc <=0 )set_bit (0 , &port->write_urbs_free);return rc; }
Greg Kroah-Hartman
maintainerPATCH 203/242 USB: serial: keyspan_pda: fix write-wakeup use-after-free
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 37faf50615412947868c49aee62f68233307f4e4 upstream.
The driver's deferred write wakeup was never flushed on disconnect, something which could lead to the driver port data being freed while the wakeup work is still scheduled.
Fix this by using the usb-serial write wakeup which gets cancelled properly on disconnect.
--- drivers/usb/serial/keyspan_pda.c | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-)
drivers/usb/serial/keyspan_pda.c +3 -14
@@ -47,8 +47,7 @@struct keyspan_pda_private {int tx_room;int tx_throttled; -struct work_struct wakeup_work; -struct work_struct unthrottle_work; +struct work_struct unthrottle_work;struct usb_serial *serial;struct usb_serial_port *port; };
@@ -101,15 +100,6 @@ static const struct usb_device_id id_tab };#endif -static void keyspan_pda_wakeup_write (struct work_struct *work) -{ -struct keyspan_pda_private *priv = - container_of(work, struct keyspan_pda_private, wakeup_work); -struct usb_serial_port *port = priv->port; - -tty_port_tty_wakeup (&port->port); -} -static void keyspan_pda_request_unthrottle (struct work_struct *work) { struct keyspan_pda_private *priv =
@@ -187,7 +177,7 @@ static void keyspan_pda_rx_interrupt(strcase 2 :/* tx unthrottle interrupt */ priv->tx_throttled =0 ;/* queue up a wakeup at scheduler time */ -schedule_work (&priv->wakeup_work); +usb_serial_port_softint (port);break ;default :break ;
@@ -567,7 +557,7 @@ static void keyspan_pda_write_bulk_callb priv =usb_get_serial_port_data (port);/* queue up a wakeup at scheduler time */ -schedule_work (&priv->wakeup_work); +usb_serial_port_softint (port); }
@@ -720,7 +710,6 @@ static int keyspan_pda_port_probe(structif (!priv)return -ENOMEM ; -INIT_WORK (&priv->wakeup_work, keyspan_pda_wakeup_write);INIT_WORK (&priv->unthrottle_work, keyspan_pda_request_unthrottle); priv->serial = port->serial; priv->port = port;
Greg Kroah-Hartman
maintainerPATCH 204/242 USB: serial: keyspan_pda: fix tx-unthrottle use-after-free
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 49fbb8e37a961396a5b6c82937c70df91de45e9d upstream.
The driver's transmit-unthrottle work was never flushed on disconnect, something which could lead to the driver port data being freed while the unthrottle work is still scheduled.
Fix this by cancelling the unthrottle work when shutting down the port.
--- drivers/usb/serial/keyspan_pda.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/keyspan_pda.c +4 -0
@@ -651,8 +651,12 @@ error: }static void keyspan_pda_close (struct usb_serial_port *port) { +struct keyspan_pda_private *priv =usb_get_serial_port_data (port); +usb_kill_urb (port->write_urb);usb_kill_urb (port->interrupt_in_urb); + +cancel_work_sync (&priv->unthrottle_work); }
Greg Kroah-Hartman
maintainerPATCH 205/242 USB: serial: keyspan_pda: fix write unthrottling
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 320f9028c7873c3c7710e8e93e5c979f4c857490 upstream.
The driver did not update its view of the available device buffer space until write() was called in task context. This meant that write_room() would return 0 even after the device had sent a write-unthrottle notification, something which could lead to blocked writers not being woken up (e.g. when using OPOST).
Note that we must also request an unthrottle notification is case a write() request fills the device buffer exactly.
--- drivers/usb/serial/keyspan_pda.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-)
drivers/usb/serial/keyspan_pda.c +20 -9
@@ -44,6 +44,8 @@#define DRIVER_AUTHOR "Brian Warner <[email protected]>"#define DRIVER_DESC "USB Keyspan PDA Converter driver" +#define KEYSPAN_TX_THRESHOLD 16 +struct keyspan_pda_private {int tx_room;int tx_throttled;
@@ -114,7 +116,7 @@ static void keyspan_pda_request_unthrott7 ,/* request_unthrottle */ USB_TYPE_VENDOR |USB_RECIP_INTERFACE |USB_DIR_OUT , -16 ,/* value: threshold */ +KEYSPAN_TX_THRESHOLD ,0 ,/* index */ NULL , 0,
@@ -133,6 +135,8 @@ static void keyspan_pda_rx_interrupt(strint retval;int status = urb->status;struct keyspan_pda_private *priv; +unsigned long flags; + priv =usb_get_serial_port_data (port);switch (status) {
@@ -175,7 +179,10 @@ static void keyspan_pda_rx_interrupt(strcase 1 :/* modemline change */ break ;case 2 :/* tx unthrottle interrupt */ +spin_lock_irqsave (&port->lock, flags); priv->tx_throttled =0 ; + priv->tx_room =max (priv->tx_room,KEYSPAN_TX_THRESHOLD ); +spin_unlock_irqrestore (&port->lock, flags);/* queue up a wakeup at scheduler time */ usb_serial_port_softint (port);break ;
@@ -509,7 +516,8 @@ static int keyspan_pda_write(struct tty_ goto exit; } } -if (count > priv->tx_room) { + +if (count >= priv->tx_room) {/* we're about to completely fill the Tx buffer, so we'll be throttled afterwards. */ count = priv->tx_room;
@@ -564,14 +572,17 @@ static void keyspan_pda_write_bulk_callbstatic int keyspan_pda_write_room (struct tty_struct *tty) {struct usb_serial_port *port = tty->driver_data; -struct keyspan_pda_private *priv; - priv =usb_get_serial_port_data (port); -/* used by n_tty.c for processing of tabs and such. Giving it our -conservative guess is probably good enough, but needs testing by -running a console through the device. */ -return priv->tx_room; -} +struct keyspan_pda_private *priv =usb_get_serial_port_data (port); +unsigned long flags; +int room =0 ; + +spin_lock_irqsave (&port->lock, flags); +if (test_bit (0 , &port->write_urbs_free) && !priv->tx_throttled) + room = priv->tx_room; +spin_unlock_irqrestore (&port->lock, flags); +return room; +}static int keyspan_pda_chars_in_buffer (struct tty_struct *tty) {
Greg Kroah-Hartman
maintainerPATCH 206/242 Btrfs: fix selftests failure due to uninitialized i_mode in test inodes
In reply to Greg Kroah-HartmanFrom: Filipe Manana <[email protected]>
commit 9f7fec0ba89108b9385f1b9fb167861224912a4a upstream
Some of the self tests create a test inode, setup some extents and then do calls to btrfs_get_extent() to test that the corresponding extent maps exist and are correct. However btrfs_get_extent(), since the 5.2 merge window, now errors out when it finds a regular or prealloc extent for an inode that does not correspond to a regular file (its ->i_mode is not S_IFREG). This causes the self tests to fail sometimes, specially when KASAN, slub_debug and page poisoning are enabled:
$ modprobe btrfs modprobe: ERROR: could not insert 'btrfs': Invalid argument
$ dmesg [ 9414.691648] Btrfs loaded, crc32c=crc32c-intel, debug=on, assert=on, integrity-checker=on, ref-verify=on [ 9414.692655] BTRFS: selftest: sectorsize: 4096 nodesize: 4096 [ 9414.692658] BTRFS: selftest: running btrfs free space cache tests [ 9414.692918] BTRFS: selftest: running extent only tests [ 9414.693061] BTRFS: selftest: running bitmap only tests [ 9414.693366] BTRFS: selftest: running bitmap and extent tests [ 9414.696455] BTRFS: selftest: running space stealing from bitmap to extent tests [ 9414.697131] BTRFS: selftest: running extent buffer operation tests [ 9414.697133] BTRFS: selftest: running btrfs_split_item tests [ 9414.697564] BTRFS: selftest: running extent I/O tests [ 9414.697583] BTRFS: selftest: running find delalloc tests [ 9415.081125] BTRFS: selftest: running find_first_clear_extent_bit test [ 9415.081278] BTRFS: selftest: running extent buffer bitmap tests [ 9415.124192] BTRFS: selftest: running inode tests [ 9415.124195] BTRFS: selftest: running btrfs_get_extent tests [ 9415.127909] BTRFS: selftest: running hole first btrfs_get_extent test [ 9415.128343] BTRFS critical (device (efault)): regular/prealloc extent found for non-regular inode 256 [ 9415.131428] BTRFS: selftest: fs/btrfs/tests/inode-tests.c:904 expected a real extent, got 0
This happens because the test inodes are created without ever initializing the i_mode field of the inode, and neither VFS's new_inode() nor the btrfs callback btrfs_alloc_inode() initialize the i_mode. Initialization of the i_mode is done through the various callbacks used by the VFS to create new inodes (regular files, directories, symlinks, tmpfiles, etc), which all call btrfs_new_inode() which in turn calls inode_init_owner(), which sets the inode's i_mode. Since the tests only uses new_inode() to create the test inodes, the i_mode was never initialized.
This always happens on a VM I used with kasan, slub_debug and many other debug facilities enabled. It also happened to someone who reported this on bugzilla (on a 5.3-rc).
Fix this by setting i_mode to S_IFREG at btrfs_new_test_inode().
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204397
--- fs/btrfs/tests/btrfs-tests.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
fs/btrfs/tests/btrfs-tests.c +7 -1
@@ -51,7 +51,13 @@ static struct file_system_type test_typestruct inode *btrfs_new_test_inode (void ) { -return new_inode (test_mnt->mnt_sb); +struct inode *inode; + + inode =new_inode (test_mnt->mnt_sb); +if (inode) +inode_init_owner (inode,NULL ,S_IFREG ); + +return inode; }static int btrfs_init_test_fs (void )
Greg Kroah-Hartman
maintainerPATCH 207/242 btrfs: fix return value mixup in btrfs_get_extent
In reply to Greg Kroah-HartmanFrom: Pavel Machek <[email protected]>
commit 881a3a11c2b858fe9b69ef79ac5ee9978a266dc9 upstream
btrfs_get_extent() sets variable ret, but out: error path expect error to be in variable err so the error code is lost.
--- fs/btrfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/inode.c +1 -1
@@ -7179,7 +7179,7 @@ again: found_type == BTRFS_FILE_EXTENT_PREALLOC) {/* Only regular file could have regular/prealloc extent */ if (!S_ISREG (inode->vfs_inode.i_mode)) { - ret = -EUCLEAN ; + err = -EUCLEAN ;btrfs_crit (fs_info,"regular/prealloc extent found for non-regular inode %llu" ,btrfs_ino (inode));
Greg Kroah-Hartman
maintainerPATCH 208/242 ext4: fix a memory leak of ext4_free_data
In reply to Greg Kroah-HartmanFrom: Chunguang Xu <[email protected]>
commit cca415537244f6102cbb09b5b90db6ae2c953bdd upstream.
When freeing metadata, we will create an ext4_free_data and insert it into the pending free list. After the current transaction is committed, the object will be freed.
ext4_mb_free_metadata() will check whether the area to be freed overlaps with the pending free list. If true, return directly. At this time, ext4_free_data is leaked. Fortunately, the probability of this problem is small, since it only occurs if the file system is corrupted such that a block is claimed by more one inode and those inodes are deleted within a single jbd2 transaction.
--- fs/ext4/mballoc.c | 1 + 1 file changed, 1 insertion(+)
fs/ext4/mballoc.c +1 -0
@@ -4718,6 +4718,7 @@ ext4_mb_free_metadata(handle_t *handle,ext4_group_first_block_no (sb, group) +EXT4_C2B (sbi, cluster), "Block already on to-be-freed list"); +kmem_cache_free (ext4_free_data_cachep, new_entry);return 0 ; } }
Greg Kroah-Hartman
maintainerPATCH 209/242 ext4: fix deadlock with fs freezing and EA inodes
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit 46e294efc355c48d1dd4d58501aa56dac461792a upstream.
Xattr code using inodes with large xattr data can end up dropping last inode reference (and thus deleting the inode) from places like ext4_xattr_set_entry(). That function is called with transaction started and so ext4_evict_inode() can deadlock against fs freezing like:
CPU1 CPU2
removexattr() freeze_super()
vfs_removexattr()
ext4_xattr_set()
handle = ext4_journal_start()
...
ext4_xattr_set_entry()
iput(old_ea_inode)
ext4_evict_inode(old_ea_inode)
sb->s_writers.frozen = SB_FREEZE_FS;
sb_wait_write(sb, SB_FREEZE_FS);
ext4_freeze()
jbd2_journal_lock_updates()
-> blocks waiting for all
handles to stop
sb_start_intwrite()
-> blocks as sb is already in SB_FREEZE_FS stateGenerally it is advisable to delete inodes from a separate transaction as it can consume quite some credits however in this case it would be quite clumsy and furthermore the credits for inode deletion are quite limited and already accounted for. So just tweak ext4_evict_inode() to avoid freeze protection if we have transaction already started and thus it is not really needed anyway.
--- fs/ext4/inode.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-)
fs/ext4/inode.c +15 -6
@@ -202,6 +202,7 @@ void ext4_evict_inode(struct inode *inod*/ int extra_credits =6 ;struct ext4_xattr_inode_array *ea_inode_array =NULL ; +bool freeze_protected = false;trace_ext4_evict_inode (inode);
@@ -249,9 +250,14 @@ void ext4_evict_inode(struct inode *inod/* * Protect us against freezing - iput() caller didn't have to have any -* protection against it -*/ -sb_start_intwrite (inode->i_sb); +* protection against it. When we are in a running transaction though, +* we are already protected against freezing and we cannot grab further +* protection due to lock ordering constraints. +*/ +if (!ext4_journal_current_handle ()) { +sb_start_intwrite (inode->i_sb); + freeze_protected = true; + }if (!IS_NOQUOTA (inode)) extra_credits +=EXT4_MAXQUOTAS_DEL_BLOCKS (inode->i_sb);
@@ -270,7 +276,8 @@ void ext4_evict_inode(struct inode *inod* cleaned up. */ ext4_orphan_del (NULL , inode); -sb_end_intwrite (inode->i_sb); +if (freeze_protected) +sb_end_intwrite (inode->i_sb); goto no_delete; }
@@ -311,7 +318,8 @@ void ext4_evict_inode(struct inode *inod stop_handle:ext4_journal_stop (handle);ext4_orphan_del (NULL , inode); -sb_end_intwrite (inode->i_sb); +if (freeze_protected) +sb_end_intwrite (inode->i_sb);ext4_xattr_inode_array_free (ea_inode_array); goto no_delete; }
@@ -340,7 +348,8 @@ stop_handle:else ext4_free_inode (handle, inode);ext4_journal_stop (handle); -sb_end_intwrite (inode->i_sb); +if (freeze_protected) +sb_end_intwrite (inode->i_sb);ext4_xattr_inode_array_free (ea_inode_array);return ; no_delete:
Greg Kroah-Hartman
maintainerPATCH 210/242 KVM: arm64: Introduce handling of AArch32 TTBCR2 traps
In reply to Greg Kroah-HartmanFrom: Marc Zyngier <[email protected]>
commit ca4e514774930f30b66375a974b5edcbebaf0e7e upstream.
ARMv8.2 introduced TTBCR2, which shares TCR_EL1 with TTBCR. Gracefully handle traps to this register when HCR_EL2.TVM is set.
--- arch/arm64/include/asm/kvm_host.h | 1 + arch/arm64/kvm/sys_regs.c | 1 + 2 files changed, 2 insertions(+)
arch/arm64/include/asm/kvm_host.h +1 -0
@@ -158,6 +158,7 @@ enum vcpu_sysreg {#define c2_TTBR1 (TTBR1_EL1 * 2)/* Translation Table Base Register 1 */ #define c2_TTBR1_high (c2_TTBR1 + 1)/* TTBR1 top 32 bits */ #define c2_TTBCR (TCR_EL1 * 2)/* Translation Table Base Control R. */ +#define c2_TTBCR2 (c2_TTBCR + 1)/* Translation Table Base Control R. 2 */ #define c3_DACR (DACR32_EL2 * 2)/* Domain Access Control Register */ #define c5_DFSR (ESR_EL1 * 2)/* Data Fault Status Register */ #define c5_IFSR (IFSR32_EL2 * 2)/* Instruction Fault Status Register */
arch/arm64/kvm/sys_regs.c +1 -0
@@ -1286,6 +1286,7 @@ static const struct sys_reg_desc cp15_re { Op1( 0), CRn( 2), CRm( 0), Op2( 0), access_vm_reg, NULL, c2_TTBR0 }, { Op1( 0), CRn( 2), CRm( 0), Op2( 1), access_vm_reg, NULL, c2_TTBR1 }, { Op1( 0), CRn( 2), CRm( 0), Op2( 2), access_vm_reg, NULL, c2_TTBCR }, + { Op1( 0), CRn( 2), CRm( 0), Op2( 3), access_vm_reg, NULL, c2_TTBCR2 }, { Op1( 0), CRn( 3), CRm( 0), Op2( 0), access_vm_reg, NULL, c3_DACR }, { Op1( 0), CRn( 5), CRm( 0), Op2( 0), access_vm_reg, NULL, c5_DFSR }, { Op1( 0), CRn( 5), CRm( 0), Op2( 1), access_vm_reg, NULL, c5_IFSR },
Greg Kroah-Hartman
maintainerPATCH 211/242 ARM: dts: at91: sama5d2: fix CAN message ram offset and size
In reply to Greg Kroah-HartmanFrom: Nicolas Ferre <[email protected]>
commit 85b8350ae99d1300eb6dc072459246c2649a8e50 upstream.
CAN0 and CAN1 instances share the same message ram configured at 0x210000 on sama5d2 Linux systems.
According to current configuration of CAN0, we need 0x1c00 bytes so that the CAN1 don't overlap its message ram:
64 x RX FIFO0 elements => 64 x 72 bytes
32 x TXE (TX Event FIFO) elements => 32 x 8 bytes
32 x TXB (TX Buffer) elements => 32 x 72 bytes
So a total of 7168 bytes (0x1C00).
Fix offset to match this needed size.
Make the CAN0 message ram ioremap match exactly this size so that is easily understandable. Adapt CAN1 size accordingly.
--- arch/arm/boot/dts/sama5d2.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm/boot/dts/sama5d2.dtsi +3 -3
@@ -1294,7 +1294,7 @@ can0: can@f8054000 { compatible = "bosch,m_can"; - reg = <0xf8054000 0x4000>, <0x210000 0x4000>; + reg = <0xf8054000 0x4000>, <0x210000 0x1c00>; reg-names = "m_can", "message_ram"; interrupts = <56 IRQ_TYPE_LEVEL_HIGH 7>, <64 IRQ_TYPE_LEVEL_HIGH 7>;
@@ -1485,7 +1485,7 @@ can1: can@fc050000 { compatible = "bosch,m_can"; - reg = <0xfc050000 0x4000>, <0x210000 0x4000>; + reg = <0xfc050000 0x4000>, <0x210000 0x3800>; reg-names = "m_can", "message_ram"; interrupts = <57 IRQ_TYPE_LEVEL_HIGH 7>, <65 IRQ_TYPE_LEVEL_HIGH 7>;
@@ -1495,7 +1495,7 @@ assigned-clocks = <&can1_gclk>; assigned-clock-parents = <&utmi>; assigned-clock-rates = <40000000>; - bosch,mram-cfg = <0x1100 0 0 64 0 0 32 32>; + bosch,mram-cfg = <0x1c00 0 0 64 0 0 32 32>; status = "disabled"; };
Greg Kroah-Hartman
maintainerPATCH 212/242 powerpc/rtas: Fix typo of ibm,open-errinjct in RTAS filter
In reply to Greg Kroah-HartmanFrom: Tyrel Datwyler <[email protected]>
commit f10881a46f8914428110d110140a455c66bdf27b upstream.
Commit bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace") introduced the following error when invoking the errinjct userspace tool:
[root@ltcalpine2-lp5 librtas]# errinjct open
[327884.071171] sys_rtas: RTAS call blocked - exploit attempt? [327884.071186] sys_rtas: token=0x26, nargs=0 (called by errinjct) errinjct: Could not open RTAS error injection facility errinjct: librtas: open: Unexpected I/O error
The entry for ibm,open-errinjct in rtas_filter array has a typo where the "j" is omitted in the rtas call name. After fixing this typo the errinjct tool functions again as expected.
[root@ltcalpine2-lp5 linux]# errinjct open
RTAS error injection facility open, token = 1
--- arch/powerpc/kernel/rtas.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/rtas.c +1 -1
@@ -1094,7 +1094,7 @@ static struct rtas_filter rtas_filters[] { "ibm,display-message", -1, 0, -1, -1, -1 }, { "ibm,errinjct", -1, 2, -1, -1, -1, 1024 }, { "ibm,close-errinjct", -1, -1, -1, -1, -1 }, - { "ibm,open-errinct", -1, -1, -1, -1, -1 }, + { "ibm,open-errinjct", -1, -1, -1, -1, -1 }, { "ibm,get-config-addr-info2", -1, -1, -1, -1, -1 }, { "ibm,get-dynamic-sensor-state", -1, 1, -1, -1, -1 }, { "ibm,get-indices", -1, 2, 3, -1, -1 },
Greg Kroah-Hartman
maintainerPATCH 213/242 powerpc/xmon: Change printk() to pr_cont()
In reply to Greg Kroah-HartmanFrom: Christophe Leroy <[email protected]>
commit 7c6c86b36a36dd4a13d30bba07718e767aa2e7a1 upstream.
Since some time now, printk() adds carriage return, leading to unusable xmon output if there is no udbg backend available:
[ 54.288722] sysrq: Entering xmon [ 54.292209] Vector: 0 at [cace3d2c] [ 54.292274] pc: [ 54.292331] c0023650 [ 54.292468] : xmon+0x28/0x58 [ 54.292519] [ 54.292574] lr: [ 54.292630] c0023724 [ 54.292749] : sysrq_handle_xmon+0xa4/0xfc [ 54.292801] [ 54.292867] sp: cace3de8 [ 54.292931] msr: 9032 [ 54.292999] current = 0xc28d0000 [ 54.293072] pid = 377, comm = sh [ 54.293157] Linux version 5.10.0-rc6-s3k-dev-01364-gedf13f0ccd76-dirty ([email protected]) (powerpc64-linux-gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34) #4211 PREEMPT Fri Dec 4 09:32:11 UTC 2020 [ 54.293287] enter ? for help [ 54.293470] [cace3de8] [ 54.293532] c0023724 [ 54.293654] sysrq_handle_xmon+0xa4/0xfc [ 54.293711] (unreliable) ... [ 54.296002] [ 54.296159] --- Exception: c01 (System Call) at [ 54.296217] 0fd4e784 [ 54.296303] [ 54.296375] SP (7fca6ff0) is in userspace [ 54.296431] mon> [ 54.296484] <no input ...>
Use pr_cont() instead.
--- arch/powerpc/xmon/nonstdio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/xmon/nonstdio.c +1 -1
@@ -182,7 +182,7 @@ void xmon_printf(const char *format, ...if (n && rc ==0 ) {/* No udbg hooks, fallback to printk() - dangerous */ -printk ("%s" , xmon_outbuf); +pr_cont ("%s" , xmon_outbuf); } }
Greg Kroah-Hartman
maintainerPATCH 214/242 powerpc/powernv/memtrace: Dont leak kernel memory to user space
In reply to Greg Kroah-HartmanFrom: David Hildenbrand <[email protected]>
commit c74cf7a3d59a21b290fe0468f5b470d0b8ee37df upstream.
We currently leak kernel memory to user space, because memory offlining doesn't do any implicit clearing of memory and we are missing explicit clearing of memory.
Let's keep it simple and clear pages before removing the linear mapping.
Reproduced in QEMU/TCG with 10 GiB of main memory:
[root@localhost ~]# dd obs=9G if=/dev/urandom of=/dev/null
[... wait until "free -m" used counter no longer changes and cancel] 19665802+0 records in
1+0 records out
9663676416 bytes (9.7 GB, 9.0 GiB) copied, 135.548 s, 71.3 MB/s [root@localhost ~]# cat /sys/devices/system/memory/block_size_bytes 40000000
[root@localhost ~]# echo 0x40000000 > /sys/kernel/debug/powerpc/memtrace/enable
[ 402.978663][ T1086] page:000000001bc4bc74 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x24900 [ 402.980063][ T1086] flags: 0x7ffff000001000(reserved) [ 402.980415][ T1086] raw: 007ffff000001000 c00c000000924008 c00c000000924008 0000000000000000 [ 402.980627][ T1086] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 402.980845][ T1086] page dumped because: unmovable page [ 402.989608][ T1086] Offlined Pages 16384 [ 403.324155][ T1086] memtrace: Allocated trace memory on node 0 at 0x0000000200000000
Before this patch:
[root@localhost ~]# hexdump -C /sys/kernel/debug/powerpc/memtrace/00000000/trace | head
00000000 c8 25 72 51 4d 26 36 c5 5c c2 56 15 d5 1a cd 10 |.%rQM&6.\.V.....|
00000010 19 b9 50 b2 cb e3 60 b8 ec 0a f3 ec 4b 3c 39 f0 |..P...`.....K<9.|$
00000020 4e 5a 4c cf bd 26 19 ff 37 79 13 67 24 b7 b8 57 |NZL..&..7y.g$..W|$
00000030 98 3e f5 be 6f 14 6a bd a4 52 bc 6e e9 e0 c1 5d |.>..o.j..R.n...]|$
00000040 76 b3 ae b5 88 d7 da e3 64 23 85 2c 10 88 07 b6 |v.......d#.,....|$
00000050 9a d8 91 de f7 50 27 69 2e 64 9c 6f d3 19 45 79 |.....P'i.d.o..Ey|$
00000060 6a 6f 8a 61 71 19 1f c7 f1 df 28 26 ca 0f 84 55 |jo.aq.....(&...U|$
00000070 01 3f be e4 e2 e1 da ff 7b 8c 8e 32 37 b4 24 53 |.?......{..27.$S|$
00000080 1b 70 30 45 56 e6 8c c4 0e b5 4c fb 9f dd 88 06 |.p0EV.....L.....|$
00000090 ef c4 18 79 f1 60 b1 5c 79 59 4d f4 36 d7 4a 5c |...y.`.\yYM.6.J\|$After this patch:
[root@localhost ~]# hexdump -C /sys/kernel/debug/powerpc/memtrace/00000000/trace | head 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
40000000
--- arch/powerpc/platforms/powernv/memtrace.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
arch/powerpc/platforms/powernv/memtrace.c +22 -0
@@ -99,6 +99,23 @@ static int change_memblock_state(structreturn 0 ; } +static void memtrace_clear_range (unsigned long start_pfn, +unsigned long nr_pages) +{ +unsigned long pfn; + +/* +* As pages are offline, we cannot trust the memmap anymore. As HIGHMEM +* does not apply, avoid passing around "struct page" and use +* clear_page() instead directly. +*/ +for (pfn = start_pfn; pfn < start_pfn + nr_pages; pfn++) { +if (IS_ALIGNED (pfn,PAGES_PER_SECTION )) +cond_resched (); +clear_page (__va (PFN_PHYS (pfn))); + } +} +/* called with device_hotplug_lock held */ static bool memtrace_offline_pages (u32 nid,u64 start_pfn,u64 nr_pages) {
@@ -144,6 +161,11 @@ static u64 memtrace_alloc_node(u32 nid,for (base_pfn = end_pfn; base_pfn > start_pfn; base_pfn -= nr_pages) {if (memtrace_offline_pages (nid, base_pfn, nr_pages) == true) {/* +* Clear the range while we still have a linear +* mapping. +*/ +memtrace_clear_range (base_pfn, nr_pages); +/* * Remove memory in memory block size chunks so that * iomem resources are always split to the same size and * we never try to remove memory that spans two iomem
Greg Kroah-Hartman
maintainerPATCH 215/242 ima: Dont modify file descriptor mode on the fly
In reply to Greg Kroah-HartmanFrom: Roberto Sassu <[email protected]>
commit 207cdd565dfc95a0a5185263a567817b7ebf5467 upstream.
Commit a408e4a86b36b ("ima: open a new file instance if no read permissions") already introduced a second open to measure a file when the original file descriptor does not allow it. However, it didn't remove the existing method of changing the mode of the original file descriptor, which is still necessary if the current process does not have enough privileges to open a new one.
Changing the mode isn't really an option, as the filesystem might need to do preliminary steps to make the read possible. Thus, this patch removes the code and keeps the second open as the only option to measure a file when it is unreadable with the original file descriptor.
--- security/integrity/ima/ima_crypto.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-)
security/integrity/ima/ima_crypto.c +5 -15
@@ -432,7 +432,7 @@ int ima_calc_file_hash(struct file *fileloff_t i_size;int rc;struct file *f = file; -bool new_file_instance = false, modified_mode = false; +bool new_file_instance = false;/* * For consistency, fail file's opened with the O_DIRECT flag on
@@ -450,18 +450,10 @@ int ima_calc_file_hash(struct file *file O_TRUNC | O_CREAT | O_NOCTTY | O_EXCL); flags |=O_RDONLY ; f =dentry_open (&file->f_path, flags, file->f_cred); -if (IS_ERR (f)) { -/* -* Cannot open the file again, lets modify f_mode -* of original and continue -*/ -pr_info_ratelimited ("Unable to reopen file for reading.\n" ); - f = file; - f->f_mode |=FMODE_READ ; - modified_mode = true; - }else { - new_file_instance = true; - } +if (IS_ERR (f)) +return PTR_ERR (f); + + new_file_instance = true; } i_size =i_size_read (file_inode (f));
@@ -476,8 +468,6 @@ int ima_calc_file_hash(struct file *file out:if (new_file_instance)fput (f); -else if (modified_mode) - f->f_mode &= ~FMODE_READ ;return rc; }
Greg Kroah-Hartman
maintainerPATCH 216/242 ceph: fix race in concurrent __ceph_remove_cap invocations
In reply to Greg Kroah-HartmanFrom: Luis Henriques <[email protected]>
commit e5cafce3ad0f8652d6849314d951459c2bff7233 upstream.
A NULL pointer dereference may occur in __ceph_remove_cap with some of the callbacks used in ceph_iterate_session_caps, namely trim_caps_cb and remove_session_caps_cb. Those callers hold the session->s_mutex, so they are prevented from concurrent execution, but ceph_evict_inode does not.
Since the callers of this function hold the i_ceph_lock, the fix is simply a matter of returning immediately if caps->ci is NULL.
Cc: [email protected]
URL: https://tracker.ceph.com/issues/43272
--- fs/ceph/caps.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
fs/ceph/caps.c +9 -2
@@ -929,12 +929,19 @@ void __ceph_remove_cap(struct ceph_cap * {struct ceph_mds_session *session = cap->session;struct ceph_inode_info *ci = cap->ci; -struct ceph_mds_client *mdsc = -ceph_sb_to_client (ci->vfs_inode.i_sb)->mdsc; +struct ceph_mds_client *mdsc;int removed =0 ; +/* 'ci' being NULL means the remove have already occurred */ +if (!ci) { +dout ("%s: cap inode is NULL\n" , __func__); +return ; + } +dout ("__ceph_remove_cap %p from %p\n" , cap, &ci->vfs_inode); + mdsc =ceph_inode_to_client (&ci->vfs_inode)->mdsc; +/* remove from inode's cap rbtree, and clear auth cap */ rb_erase (&cap->ci_node, &ci->i_caps);if (ci->i_auth_cap == cap)
Greg Kroah-Hartman
maintainerPATCH 217/242 jffs2: Fix GC exit abnormally
In reply to Greg Kroah-HartmanFrom: Zhe Li <[email protected]>
commit 9afc9a8a4909fece0e911e72b1060614ba2f7969 upstream.
The log of this problem is:
jffs2: Error garbage collecting node at 0x***!
jffs2: No space for garbage collection. Aborting GC thread
This is because GC believe that it do nothing, so it abort.
After going over the image of jffs2, I find a scene that can trigger this problem stably.
The scene is: there is a normal dirent node at summary-area, but abnormal at corresponding not-summary-area with error name_crc.
The reason that GC exit abnormally is because it find that abnormal dirent node to GC, but when it goes to function jffs2_add_fd_to_list, it cannot meet the condition listed below:
if ((*prev)->nhash == new->nhash && !strcmp((*prev)->name, new->name))
So no node is marked obsolete, statistical information of erase_block do not change, which cause GC exit abnormally.
The root cause of this problem is: we do not check the name_crc of the abnormal dirent node with summary is enabled.
Noticed that in function jffs2_scan_dirent_node, we use function jffs2_scan_dirty_space to deal with the dirent node with error name_crc. So this patch add a checking code in function read_direntry to ensure the correctness of dirent node. If checked failed, the dirent node will be marked obsolete so GC will pass this node and this problem will be fixed.
--- fs/jffs2/readinode.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
fs/jffs2/readinode.c +16 -0
@@ -672,6 +672,22 @@ static inline int read_direntry(struct jjffs2_free_full_dirent (fd);return -EIO ; } + +#ifdef CONFIG_JFFS2_SUMMARY +/* +* we use CONFIG_JFFS2_SUMMARY because without it, we +* have checked it while mounting +*/ + crc =crc32 (0 , fd->name, rd->nsize); +if (unlikely (crc !=je32_to_cpu (rd->name_crc))) { +JFFS2_NOTICE ("name CRC failed on dirent node at" +"%#08x: read %#08x,calculated %#08x\n" , +ref_offset (ref),je32_to_cpu (rd->node_crc), crc); +jffs2_mark_node_obsolete (c, ref); +jffs2_free_full_dirent (fd); +return 0 ; + } +#endif } fd->nhash =full_name_hash (NULL , fd->name, rd->nsize);
Greg Kroah-Hartman
maintainerPATCH 218/242 jfs: Fix array index bounds check in dbAdjTree
In reply to Greg Kroah-HartmanFrom: Dave Kleikamp <[email protected]>
commit c61b3e4839007668360ed8b87d7da96d2e59fc6c upstream.
Bounds checking tools can flag a bug in dbAdjTree() for an array index out of bounds in dmt_stree. Since dmt_stree can refer to the stree in both structures dmaptree and dmapctl, use the larger array to eliminate the false positive.
--- fs/jfs/jfs_dmap.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/jfs/jfs_dmap.h +1 -1
@@ -196,7 +196,7 @@ typedef union dmtree {#define dmt_leafidx t1.leafidx#define dmt_height t1.height#define dmt_budmin t1.budmin -#define dmt_stree t1.stree +#define dmt_stree t2.stree/* * on-disk aggregate disk allocation map descriptor.
Greg Kroah-Hartman
maintainerPATCH 219/242 drm/dp_aux_dev: check aux_dev before use in drm_dp_aux_dev_get_by_minor()
In reply to Greg Kroah-HartmanFrom: Zwane Mwaikambo <[email protected]>
commit 73b62cdb93b68d7e2c1d373c6a411bc00c53e702 upstream.
I observed this when unplugging a DP monitor whilst a computer is asleep and then waking it up. This left DP chardev nodes still being present on the filesystem and accessing these device nodes caused an oops because drm_dp_aux_dev_get_by_minor() assumes a device exists if it is opened. This can also be reproduced by creating a device node with mknod(1) and issuing an open(2)
[166164.933198] BUG: kernel NULL pointer dereference, address: 0000000000000018 [166164.933202] #PF: supervisor read access in kernel mode [166164.933204] #PF: error_code(0x0000) - not-present page [166164.933205] PGD 0 P4D 0 [166164.933208] Oops: 0000 [#1] PREEMPT SMP NOPTI [166164.933211] CPU: 4 PID: 99071 Comm: fwupd Tainted: G W 5.8.0-rc6+ #1 [166164.933213] Hardware name: LENOVO 20RD002VUS/20RD002VUS, BIOS R16ET25W (1.11 ) 04/21/2020 [166164.933232] RIP: 0010:drm_dp_aux_dev_get_by_minor+0x29/0x70 [drm_kms_helper] [166164.933234] Code: 00 0f 1f 44 00 00 55 48 89 e5 41 54 41 89 fc 48 c7 c7 60 01 a4 c0 e8 26 ab 30 d7 44 89 e6 48 c7 c7 80 01 a4 c0 e8 47 94 d6 d6 <8b> 50 18 49 89 c4 48 8d 78 18 85 d2 74 33 8d 4a 01 89 d0 f0 0f b1 [166164.933236] RSP: 0018:ffffb7d7c41cbbf0 EFLAGS: 00010246 [166164.933237] RAX: 0000000000000000 RBX: ffff8a90001fe900 RCX: 0000000000000000 [166164.933238] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffffc0a40180 [166164.933239] RBP: ffffb7d7c41cbbf8 R08: 0000000000000000 R09: ffff8a93e157d6d0 [166164.933240] R10: 0000000000000000 R11: ffffffffc0a40188 R12: 0000000000000003 [166164.933241] R13: ffff8a9402200e80 R14: ffff8a90001fe900 R15: 0000000000000000 [166164.933244] FS: 00007f7fb041eb00(0000) GS:ffff8a9411500000(0000) knlGS:0000000000000000 [166164.933245] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [166164.933246] CR2: 0000000000000018 CR3: 00000000352c2003 CR4: 00000000003606e0 [166164.933247] Call Trace: [166164.933264] auxdev_open+0x1b/0x40 [drm_kms_helper] [166164.933278] chrdev_open+0xa7/0x1c0 [166164.933282] ? cdev_put.part.0+0x20/0x20 [166164.933287] do_dentry_open+0x161/0x3c0 [166164.933291] vfs_open+0x2d/0x30 [166164.933297] path_openat+0xb27/0x10e0 [166164.933306] ? atime_needs_update+0x73/0xd0 [166164.933309] do_filp_open+0x91/0x100 [166164.933313] ? __alloc_fd+0xb2/0x150 [166164.933316] do_sys_openat2+0x210/0x2d0 [166164.933318] do_sys_open+0x46/0x80 [166164.933320] __x64_sys_openat+0x20/0x30 [166164.933328] do_syscall_64+0x52/0xc0 [166164.933336] entry_SYSCALL_64_after_hwframe+0x44/0xa9
(gdb) disassemble drm_dp_aux_dev_get_by_minor+0x29 Dump of assembler code for function drm_dp_aux_dev_get_by_minor:
0x0000000000017b10 <+0>: callq 0x17b15 <drm_dp_aux_dev_get_by_minor+5> 0x0000000000017b15 <+5>: push %rbp 0x0000000000017b16 <+6>: mov %rsp,%rbp 0x0000000000017b19 <+9>: push %r12 0x0000000000017b1b <+11>: mov %edi,%r12d 0x0000000000017b1e <+14>: mov $0x0,%rdi 0x0000000000017b25 <+21>: callq 0x17b2a <drm_dp_aux_dev_get_by_minor+26> 0x0000000000017b2a <+26>: mov %r12d,%esi 0x0000000000017b2d <+29>: mov $0x0,%rdi 0x0000000000017b34 <+36>: callq 0x17b39 <drm_dp_aux_dev_get_by_minor+41> 0x0000000000017b39 <+41>: mov 0x18(%rax),%edx <========= 0x0000000000017b3c <+44>: mov %rax,%r12 0x0000000000017b3f <+47>: lea 0x18(%rax),%rdi 0x0000000000017b43 <+51>: test %edx,%edx 0x0000000000017b45 <+53>: je 0x17b7a <drm_dp_aux_dev_get_by_minor+106> 0x0000000000017b47 <+55>: lea 0x1(%rdx),%ecx 0x0000000000017b4a <+58>: mov %edx,%eax 0x0000000000017b4c <+60>: lock cmpxchg %ecx,(%rdi) 0x0000000000017b50 <+64>: jne 0x17b76 <drm_dp_aux_dev_get_by_minor+102> 0x0000000000017b52 <+66>: test %edx,%edx 0x0000000000017b54 <+68>: js 0x17b6d <drm_dp_aux_dev_get_by_minor+93> 0x0000000000017b56 <+70>: test %ecx,%ecx 0x0000000000017b58 <+72>: js 0x17b6d <drm_dp_aux_dev_get_by_minor+93> 0x0000000000017b5a <+74>: mov $0x0,%rdi 0x0000000000017b61 <+81>: callq 0x17b66 <drm_dp_aux_dev_get_by_minor+86> 0x0000000000017b66 <+86>: mov %r12,%rax 0x0000000000017b69 <+89>: pop %r12 0x0000000000017b6b <+91>: pop %rbp 0x0000000000017b6c <+92>: retq 0x0000000000017b6d <+93>: xor %esi,%esi 0x0000000000017b6f <+95>: callq 0x17b74 <drm_dp_aux_dev_get_by_minor+100> 0x0000000000017b74 <+100>: jmp 0x17b5a <drm_dp_aux_dev_get_by_minor+74> 0x0000000000017b76 <+102>: mov %eax,%edx 0x0000000000017b78 <+104>: jmp 0x17b43 <drm_dp_aux_dev_get_by_minor+51> 0x0000000000017b7a <+106>: xor %r12d,%r12d 0x0000000000017b7d <+109>: jmp 0x17b5a <drm_dp_aux_dev_get_by_minor+74>
End of assembler dump.
(gdb) list *drm_dp_aux_dev_get_by_minor+0x290x17b39 is in drm_dp_aux_dev_get_by_minor (drivers/gpu/drm/drm_dp_aux_dev.c:65).
60 static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned index)
61 {
62 struct drm_dp_aux_dev *aux_dev = NULL;
63
64 mutex_lock(&aux_idr_mutex); 65 aux_dev = idr_find(&aux_idr, index); 66 if (!kref_get_unless_zero(&aux_dev->refcount))
67 aux_dev = NULL;
68 mutex_unlock(&aux_idr_mutex);
69
(gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount $8 = 0x18
Looking at the caller, checks on the minor are pushed down to drm_dp_aux_dev_get_by_minor()
static int auxdev_open(struct inode *inode, struct file *file)
{
unsigned int minor = iminor(inode);
struct drm_dp_aux_dev *aux_dev;
aux_dev = drm_dp_aux_dev_get_by_minor(minor); <====
if (!aux_dev)
return -ENODEV;
file->private_data = aux_dev;
return 0;
}--- drivers/gpu/drm/drm_dp_aux_dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/drm_dp_aux_dev.c +1 -1
@@ -60,7 +60,7 @@ static struct drm_dp_aux_dev *drm_dp_auxmutex_lock (&aux_idr_mutex); aux_dev =idr_find (&aux_idr, index); -if (!kref_get_unless_zero (&aux_dev->refcount)) +if (aux_dev && !kref_get_unless_zero (&aux_dev->refcount)) aux_dev =NULL ;mutex_unlock (&aux_idr_mutex);
Greg Kroah-Hartman
maintainerPATCH 220/242 spi: spi-sh: Fix use-after-free on unbind
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit e77df3eca12be4b17f13cf9f215cff248c57d98f upstream.
spi_sh_remove() accesses the driver's private data after calling spi_unregister_master() even though that function releases the last reference on the spi_master and thereby frees the private data.
Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound.
--- drivers/spi/spi-sh.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-)
drivers/spi/spi-sh.c +4 -9
@@ -450,7 +450,7 @@ static int spi_sh_probe(struct platform_return irq; } - master =spi_alloc_master (&pdev->dev,sizeof (struct spi_sh_data )); + master =devm_spi_alloc_master (&pdev->dev,sizeof (struct spi_sh_data ));if (master ==NULL ) {dev_err (&pdev->dev,"spi_alloc_master error.\n" );return -ENOMEM ;
@@ -468,16 +468,14 @@ static int spi_sh_probe(struct platform_break ;default :dev_err (&pdev->dev,"No support width\n" ); - ret = -ENODEV ; - goto error1; +return -ENODEV ; } ss->irq = irq; ss->master = master; ss->addr =devm_ioremap (&pdev->dev, res->start,resource_size (res));if (ss->addr ==NULL ) {dev_err (&pdev->dev,"ioremap error.\n" ); - ret = -ENOMEM ; - goto error1; +return -ENOMEM ; }INIT_LIST_HEAD (&ss->queue);spin_lock_init (&ss->lock);
@@ -487,7 +485,7 @@ static int spi_sh_probe(struct platform_ ret =request_irq (irq, spi_sh_irq,0 ,"spi_sh" , ss);if (ret <0 ) {dev_err (&pdev->dev,"request_irq error\n" ); - goto error1; +return ret; } master->num_chipselect =2 ;
@@ -506,9 +504,6 @@ static int spi_sh_probe(struct platform_ error3:free_irq (irq, ss); - error1: -spi_master_put (master); -return ret; }
Greg Kroah-Hartman
maintainerPATCH 221/242 spi: davinci: Fix use-after-free on unbind
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit 373afef350a93519b4b8d636b0895da8650b714b upstream.
davinci_spi_remove() accesses the driver's private data after it's been freed with spi_master_put().
Fix by moving the spi_master_put() to the end of the function.
--- drivers/spi/spi-davinci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-davinci.c +1 -1
@@ -1085,13 +1085,13 @@ static int davinci_spi_remove(struct plaspi_bitbang_stop (&dspi->bitbang);clk_disable_unprepare (dspi->clk); -spi_master_put (master);if (dspi->dma_rx) {dma_release_channel (dspi->dma_rx);dma_release_channel (dspi->dma_tx); } +spi_master_put (master);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 222/242 spi: pic32: Dont leak DMA channels in probe error path
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit c575e9113bff5e024d75481613faed5ef9d465b2 upstream.
If the calls to devm_request_irq() or devm_spi_register_master() fail on probe of the PIC32 SPI driver, the DMA channels requested by pic32_spi_dma_prep() are erroneously not released. Plug the leak.
--- drivers/spi/spi-pic32.c | 1 + 1 file changed, 1 insertion(+)
drivers/spi/spi-pic32.c +1 -0
@@ -839,6 +839,7 @@ static int pic32_spi_probe(struct platforeturn 0 ; err_bailout: +pic32_spi_dma_unprep (pic32s);clk_disable_unprepare (pic32s->clk); err_master:spi_master_put (master);
Greg Kroah-Hartman
maintainerPATCH 223/242 spi: rb4xx: Dont leak SPI master in probe error path
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit a4729c3506c3eb1a6ca5c0289f4e7cafa4115065 upstream.
If the calls to devm_clk_get(), devm_spi_register_master() or clk_prepare_enable() fail on probe of the Mikrotik RB4xx SPI driver, the spi_master struct is erroneously not freed.
Fix by switching over to the new devm_spi_alloc_master() helper.
--- drivers/spi/spi-rb4xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-rb4xx.c +1 -1
@@ -148,7 +148,7 @@ static int rb4xx_spi_probe(struct platfoif (IS_ERR (spi_base))return PTR_ERR (spi_base); - master =spi_alloc_master (&pdev->dev,sizeof (*rbspi)); + master =devm_spi_alloc_master (&pdev->dev,sizeof (*rbspi));if (!master)return -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 224/242 spi: sc18is602: Dont leak SPI master in probe error path
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit 5b8c88462d83331dacb48aeaec8388117fef82e0 upstream.
If the call to devm_gpiod_get_optional() fails on probe of the NXP SC18IS602/603 SPI driver, the spi_master struct is erroneously not freed.
Fix by switching over to the new devm_spi_alloc_master() helper.
--- drivers/spi/spi-sc18is602.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-)
drivers/spi/spi-sc18is602.c +2 -11
@@ -248,13 +248,12 @@ static int sc18is602_probe(struct i2c_clstruct sc18is602_platform_data *pdata =dev_get_platdata (dev);struct sc18is602 *hw;struct spi_master *master; -int error;if (!i2c_check_functionality (client->adapter,I2C_FUNC_I2C |I2C_FUNC_SMBUS_WRITE_BYTE_DATA ))return -EINVAL ; - master =spi_alloc_master (dev,sizeof (struct sc18is602 )); + master =devm_spi_alloc_master (dev,sizeof (struct sc18is602 ));if (!master)return -ENOMEM ;
@@ -308,15 +307,7 @@ static int sc18is602_probe(struct i2c_cl master->min_speed_hz = hw->freq /128 ; master->max_speed_hz = hw->freq /4 ; - error =devm_spi_register_master (dev, master); -if (error) - goto error_reg; - -return 0 ; - -error_reg: -spi_master_put (master); -return error; +return devm_spi_register_master (dev, master); }static const struct i2c_device_id sc18is602_id[] = {
Greg Kroah-Hartman
maintainerPATCH 225/242 spi: st-ssc4: Fix unbalanced pm_runtime_disable() in probe error path
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit 5ef76dac0f2c26aeae4ee79eb830280f16d5aceb upstream.
If the calls to devm_platform_ioremap_resource(), irq_of_parse_and_map() or devm_request_irq() fail on probe of the ST SSC4 SPI driver, the runtime PM disable depth is incremented even though it was not decremented before. Fix it.
--- drivers/spi/spi-st-ssc4.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/spi/spi-st-ssc4.c +3 -2
@@ -379,13 +379,14 @@ static int spi_st_probe(struct platform_ ret =devm_spi_register_master (&pdev->dev, master);if (ret) {dev_err (&pdev->dev,"Failed to register master\n" ); - goto clk_disable; + goto rpm_disable; }return 0 ; -clk_disable: +rpm_disable:pm_runtime_disable (&pdev->dev); +clk_disable:clk_disable_unprepare (spi_st->clk); put_master:spi_master_put (master);
Greg Kroah-Hartman
maintainerPATCH 226/242 soc: qcom: smp2p: Safely acquire spinlock without IRQs
In reply to Greg Kroah-HartmanFrom: Evan Green <[email protected]>
commit fc3e62e25c3896855b7c3d72df19ca6be3459c9f upstream.
smp2p_update_bits() should disable interrupts when it acquires its spinlock. This is important because without the _irqsave, a priority inversion can occur.
This function is called both with interrupts enabled in qcom_q6v5_request_stop(), and with interrupts disabled in ipa_smp2p_panic_notifier(). IRQ handling of spinlocks should be consistent to avoid the panic notifier deadlocking because it's sitting on the thread that's already got the lock via _request_stop().
Found via lockdep.
--- drivers/soc/qcom/smp2p.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/soc/qcom/smp2p.c +3 -2
@@ -314,15 +314,16 @@ static int qcom_smp2p_inbound_entry(strustatic int smp2p_update_bits (void *data,u32 mask,u32 value) {struct smp2p_entry *entry = data; +unsigned long flags;u32 orig;u32 val; -spin_lock (&entry->lock); +spin_lock_irqsave (&entry->lock, flags); val = orig =readl (entry->value); val &= ~mask; val |= value;writel (val, entry->value); -spin_unlock (&entry->lock); +spin_unlock_irqrestore (&entry->lock, flags);if (val != orig)qcom_smp2p_kick (entry->smp2p);
Greg Kroah-Hartman
maintainerPATCH 227/242 mtd: parser: cmdline: Fix parsing of part-names with colons
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit 639a82434f16a6df0ce0e7c8595976f1293940fd upstream.
Some devices (especially QCA ones) are already using hardcoded partition names with colons in it. The OpenMesh A62 for example provides following mtd relevant information via cmdline:
root=31:11 mtdparts=spi0.0:256k(0:SBL1),128k(0:MIBIB),384k(0:QSEE),64k(0:CDT),64k(0:DDRPARAMS),64k(0:APPSBLENV),512k(0:APPSBL),64k(0:ART),64k(custom),64k(0:KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive) rootfsname=rootfs rootwait
The change to split only on the last colon between mtd-id and partitions will cause newpart to see following string for the first partition:
KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive)
Such a partition list cannot be parsed and thus the device fails to boot.
Avoid this behavior by making sure that the start of the first part-name ("(") will also be the last byte the mtd-id split algorithm is using for its colon search.
--- drivers/mtd/cmdlinepart.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
drivers/mtd/cmdlinepart.c +13 -1
@@ -228,7 +228,7 @@ static int mtdpart_setup_real(char *s)struct cmdline_mtd_partition *this_mtd;struct mtd_partition *parts;int mtd_id_len, num_parts; -char *p, *mtd_id, *semicol; +char *p, *mtd_id, *semicol, *open_parenth;/* * Replace the first ';' by a NULL char so strrchr can work
@@ -238,6 +238,14 @@ static int mtdpart_setup_real(char *s)if (semicol) *semicol ='\0' ; +/* +* make sure that part-names with ":" will not be handled as +* part of the mtd-id with an ":" +*/ + open_parenth =strchr (s,'(' ); +if (open_parenth) + *open_parenth ='\0' ; + mtd_id = s;/*
@@ -247,6 +255,10 @@ static int mtdpart_setup_real(char *s)*/ p =strrchr (s,':' ); +/* Restore the '(' now. */ +if (open_parenth) + *open_parenth ='(' ; +/* Restore the ';' now. */ if (semicol) *semicol =';' ;
Greg Kroah-Hartman
maintainerPATCH 228/242 iio: buffer: Fix demux update
In reply to Greg Kroah-HartmanFrom: Nuno Sá <[email protected]>
commit 19ef7b70ca9487773c29b449adf0c70f540a0aab upstream.
When updating the buffer demux, we will skip a scan element from the device in the case in_ind != out_ind and we enter the while loop. in_ind should only be refreshed with find_next_bit() in the end of the loop.
Note, to cause problems we need a situation where we are skippig over an element (channel not enabled) that happens to not have the same size
as the next element. Whilst this is a possible situation we haven't
actually identified any cases in mainline where it happens as most drivers have consistent channel storage sizes with the exception of the timestamp which is the last element and hence never skipped over.
--- drivers/iio/industrialio-buffer.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/iio/industrialio-buffer.c +3 -3
@@ -850,12 +850,12 @@ static int iio_buffer_update_demux(struc indio_dev->masklength, in_ind + 1);while (in_ind != out_ind) { - in_ind =find_next_bit (indio_dev->active_scan_mask, - indio_dev->masklength, - in_ind +1 ); length =iio_storage_bytes_for_si (indio_dev, in_ind);/* Make sure we are aligned */ in_loc =roundup (in_loc, length) + length; + in_ind =find_next_bit (indio_dev->active_scan_mask, + indio_dev->masklength, + in_ind +1 ); } length =iio_storage_bytes_for_si (indio_dev, in_ind); out_loc =roundup (out_loc, length);
Greg Kroah-Hartman
maintainerPATCH 229/242 iio: adc: rockchip_saradc: fix missing clk_disable_unprepare() on error in rockchip_saradc_resume
In reply to Greg Kroah-HartmanFrom: Qinglang Miao <[email protected]>
commit 560c6b914c6ec7d9d9a69fddbb5bf3bf71433e8b upstream.
Fix the missing clk_disable_unprepare() of info->pclk before return from rockchip_saradc_resume in the error handling case when fails to prepare and enable info->clk.
--- drivers/iio/adc/rockchip_saradc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/adc/rockchip_saradc.c +1 -1
@@ -384,7 +384,7 @@ static int rockchip_saradc_resume(struct ret =clk_prepare_enable (info->clk);if (ret) -return ret; +clk_disable_unprepare (info->pclk);return ret; }
Greg Kroah-Hartman
maintainerPATCH 230/242 iio:light:rpr0521: Fix timestamp alignment and prevent data leak.
In reply to Greg Kroah-HartmanFrom: Jonathan Cameron <[email protected]>
commit a61817216bcc755eabbcb1cf281d84ccad267ed1 upstream.
One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv().
This data is allocated with kzalloc() so no data can leak apart from previous readings and in this case the status byte from the device.
The forced alignment of ts is not necessary in this case but it potentially makes the code less fragile.
Quoted 1 line
From personal communications with Mikko:
We could probably split the reading of the int register, but it would mean a significant performance cost of 20 i2c clock cycles.
--- drivers/iio/light/rpr0521.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
drivers/iio/light/rpr0521.c +13 -4
@@ -197,6 +197,17 @@ struct rpr0521_data {bool pxs_need_dis;struct regmap *regmap; + +/* +* Ensure correct naturally aligned timestamp. +* Note that the read will put garbage data into +* the padding but this should not be a problem +*/ +struct { +__le16 channels[3 ]; +u8 garbage; +s64 ts__aligned(8) ; + } scan; }; static IIO_CONST_ATTR(in_intensity_scale_available, RPR0521_ALS_SCALE_AVAIL);
@@ -452,8 +463,6 @@ static irqreturn_t rpr0521_trigger_consustruct rpr0521_data *data =iio_priv (indio_dev);int err; -u8 buffer[16 ];/* 3 16-bit channels + padding + ts */ -/* Use irq timestamp when reasonable. */ if (iio_trigger_using_own (indio_dev) && data->irq_timestamp) { pf->timestamp = data->irq_timestamp;
@@ -464,11 +473,11 @@ static irqreturn_t rpr0521_trigger_consu pf->timestamp =iio_get_time_ns (indio_dev); err =regmap_bulk_read (data->regmap,RPR0521_REG_PXS_DATA , - &buffer, + data->scan.channels, (3 *2 ) +1 );/* 3 * 16-bit + (discarded) int clear reg. */ if (!err)iio_push_to_buffers_with_timestamp (indio_dev, - buffer, pf->timestamp); + &data->scan, pf->timestamp);else dev_err (&data->client->dev,"Trigger consumer can't read from sensor.\n" );
Greg Kroah-Hartman
maintainerPATCH 231/242 iio:pressure:mpl3115: Force alignment of buffer
In reply to Greg Kroah-HartmanFrom: Jonathan Cameron <[email protected]>
commit 198cf32f0503d2ad60d320b95ef6fb8243db857f upstream.
Whilst this is another case of the issue Lars reported with an array of elements of smaller than 8 bytes being passed to iio_push_to_buffers_with_timestamp(), the solution here is a bit different from the other cases and relies on __aligned working on the stack (true since 4.6?)
This one is unusual. We have to do an explicit memset() each time as we are reading 3 bytes into a potential 4 byte channel which may sometimes be a 2 byte channel depending on what is enabled. As such, moving the buffer to the heap in the iio_priv structure doesn't save us much. We can't use a nice explicit structure on the stack either as the data channels have different storage sizes and are all separately controlled.
--- drivers/iio/pressure/mpl3115.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/iio/pressure/mpl3115.c +8 -1
@@ -147,7 +147,14 @@ static irqreturn_t mpl3115_trigger_handlstruct iio_poll_func *pf = p;struct iio_dev *indio_dev = pf->indio_dev;struct mpl3115_data *data =iio_priv (indio_dev); -u8 buffer[16 ];/* 32-bit channel + 16-bit channel + padding + ts */ +/* +* 32-bit channel + 16-bit channel + padding + ts +* Note that it is possible for only one of the first 2 +* channels to be enabled. If that happens, the first element +* of the buffer may be either 16 or 32-bits. As such we cannot +* use a simple structure definition to express this data layout. +*/ +u8 buffer[16 ]__aligned(8) ;int ret, pos =0 ;mutex_lock (&data->lock);
Greg Kroah-Hartman
maintainerPATCH 232/242 iio:imu:bmi160: Fix too large a buffer.
In reply to Greg Kroah-HartmanFrom: Jonathan Cameron <[email protected]>
commit dc7de42d6b50a07b37feeba4c6b5136290fcee81 upstream.
The comment implies this device has 3 sensor types, but it only has an accelerometer and a gyroscope (both 3D). As such the buffer does not need to be as long as stated.
Note I've separated this from the following patch which fixes the alignment for passing to iio_push_to_buffers_with_timestamp() as they are different issues even if they affect the same line of code.
--- drivers/iio/imu/bmi160/bmi160_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/iio/imu/bmi160/bmi160_core.c +2 -2
@@ -385,8 +385,8 @@ static irqreturn_t bmi160_trigger_handlestruct iio_poll_func *pf = p;struct iio_dev *indio_dev = pf->indio_dev;struct bmi160_data *data =iio_priv (indio_dev); -__le16 buf[16 ]; -/* 3 sens x 3 axis x __le16 + 3 x __le16 pad + 4 x __le16 tstamp */ +__le16 buf[12 ]; +/* 2 sens x 3 axis x __le16 + 2 x __le16 pad + 4 x __le16 tstamp */ int i, ret, j =0 , base =BMI160_REG_DATA_MAGN_XOUT_L ;__le16 sample;
Greg Kroah-Hartman
maintainerPATCH 233/242 md/cluster: fix deadlock when node is doing resync job
In reply to Greg Kroah-HartmanFrom: Zhao Heming <[email protected]>
commit bca5b0658020be90b6b504ca514fd80110204f71 upstream.
md-cluster uses MD_CLUSTER_SEND_LOCK to make node can exclusively send msg. During sending msg, node can concurrently receive msg from another node. When node does resync job, grab token_lockres:EX may trigger a deadlock:
```
nodeA nodeB
-------------------- --------------------
a.
send METADATA_UPDATED
held token_lockres:EX
b.
md_do_sync
resync_info_update
send RESYNCING
+ set MD_CLUSTER_SEND_LOCK
+ wait for holding token_lockres:EX
c.
mdadm /dev/md0 --remove /dev/sdg
+ held reconfig_mutex
+ send REMOVE
+ wait_event(MD_CLUSTER_SEND_LOCK)
d.
recv_daemon //METADATA_UPDATED from A
process_metadata_update
+ (mddev_trylock(mddev) ||
MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD)
//this time, both return false forever
```Explaination:
a. A send METADATA_UPDATED
This will block another node to send msg
b. B does sync jobs, which will send RESYNCING at intervals.
This will be block for holding token_lockres:EX lock.
c. B do "mdadm --remove", which will send REMOVE.
This will be blocked by step <b>: MD_CLUSTER_SEND_LOCK is 1.
d. B recv METADATA_UPDATED msg, which send from A in step <a>.
This will be blocked by step <c>: holding mddev lock, it makes wait_event can't hold mddev lock. (btw, MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD keep ZERO in this scenario.)
There is a similar deadlock in commit 0ba959774e93 ("md-cluster: use sync way to handle METADATA_UPDATED msg") In that commit, step c is "update sb". This patch step c is "mdadm --remove".
For fixing this issue, we can refer the solution of function:metadata_update_start. Which does the same grab lock_token action. lock_comm can use the same steps to avoid deadlock. By moving MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD from lock_token to lock_comm. It enlarge a little bit window of MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD, but it is safe & can break deadlock.
Repro steps (I only triggered 3 times with hundreds tests):
two nodes share 3 iSCSI luns: sdg/sdh/sdi. Each lun size is 1GB.
```
ssh root@node2 "mdadm -S --scan"
mdadm -S --scan
for i in {g,h,i};do dd if=/dev/zero of=/dev/sd$i oflag=direct bs=1M \
count=20; done
mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sdg /dev/sdh \
--bitmap-chunk=1M
ssh root@node2 "mdadm -A /dev/md0 /dev/sdg /dev/sdh"
sleep 5
mkfs.xfs /dev/md0
mdadm --manage --add /dev/md0 /dev/sdi
mdadm --wait /dev/md0
mdadm --grow --raid-devices=3 /dev/md0
mdadm /dev/md0 --fail /dev/sdg
mdadm /dev/md0 --remove /dev/sdg
mdadm --grow --raid-devices=2 /dev/md0
```test script will hung when executing "mdadm --remove".
``` # dump stacks by "echo t > /proc/sysrq-trigger" md0_cluster_rec D 0 5329 2 0x80004000 Call Trace: __schedule+0x1f6/0x560 ? _cond_resched+0x2d/0x40 ? schedule+0x4a/0xb0 ? process_metadata_update.isra.0+0xdb/0x140 [md_cluster] ? wait_woken+0x80/0x80 ? process_recvd_msg+0x113/0x1d0 [md_cluster] ? recv_daemon+0x9e/0x120 [md_cluster] ? md_thread+0x94/0x160 [md_mod] ? wait_woken+0x80/0x80 ? md_congested+0x30/0x30 [md_mod] ? kthread+0x115/0x140 ? __kthread_bind_mask+0x60/0x60 ? ret_from_fork+0x1f/0x40 mdadm D 0 5423 1 0x00004004 Call Trace: __schedule+0x1f6/0x560 ? __schedule+0x1fe/0x560 ? schedule+0x4a/0xb0 ? lock_comm.isra.0+0x7b/0xb0 [md_cluster] ? wait_woken+0x80/0x80 ? remove_disk+0x4f/0x90 [md_cluster] ? hot_remove_disk+0xb1/0x1b0 [md_mod] ? md_ioctl+0x50c/0xba0 [md_mod] ? wait_woken+0x80/0x80 ? blkdev_ioctl+0xa2/0x2a0 ? block_ioctl+0x39/0x40 ? ksys_ioctl+0x82/0xc0 ? __x64_sys_ioctl+0x16/0x20 ? do_syscall_64+0x5f/0x150 ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 md0_resync D 0 5425 2 0x80004000 Call Trace: __schedule+0x1f6/0x560 ? schedule+0x4a/0xb0 ? dlm_lock_sync+0xa1/0xd0 [md_cluster] ? wait_woken+0x80/0x80 ? lock_token+0x2d/0x90 [md_cluster] ? resync_info_update+0x95/0x100 [md_cluster] ? raid1_sync_request+0x7d3/0xa40 [raid1] ? md_do_sync.cold+0x737/0xc8f [md_mod] ? md_thread+0x94/0x160 [md_mod] ? md_congested+0x30/0x30 [md_mod] ? kthread+0x115/0x140 ? __kthread_bind_mask+0x60/0x60 ? ret_from_fork+0x1f/0x40 ```
At last, thanks for Xiao's solution.
--- drivers/md/md-cluster.c | 67 +++++++++++++++++++++++++++--------------------- drivers/md/md.c | 6 ++-- 2 files changed, 42 insertions(+), 31 deletions(-)
drivers/md/md-cluster.c +38 -29
@@ -659,9 +659,27 @@ out:* Takes the lock on the TOKEN lock resource so no other * node can communicate while the operation is underway. */ -static int lock_token (struct md_cluster_info *cinfo,bool mddev_locked) +static int lock_token (struct md_cluster_info *cinfo) { -int error, set_bit =0 ; +int error; + + error =dlm_lock_sync (cinfo->token_lockres,DLM_LOCK_EX ); +if (error) { +pr_err ("md-cluster(%s:%d): failed to get EX on TOKEN (%d)\n" , + __func__, __LINE__, error); + }else { +/* Lock the receive sequence */ +mutex_lock (&cinfo->recv_mutex); + } +return error; +} + +/* lock_comm() +* Sets the MD_CLUSTER_SEND_LOCK bit to lock the send channel. +*/ +static int lock_comm (struct md_cluster_info *cinfo,bool mddev_locked) +{ +int rv, set_bit =0 ;struct mddev *mddev = cinfo->mddev;/*
@@ -672,34 +690,19 @@ static int lock_token(struct md_cluster_*/ if (mddev_locked && !test_bit (MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD , &cinfo->state)) { - error =test_and_set_bit_lock (MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD , + rv =test_and_set_bit_lock (MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD , &cinfo->state); -WARN_ON_ONCE (error); +WARN_ON_ONCE (rv);md_wakeup_thread (mddev->thread); set_bit =1 ; } - error =dlm_lock_sync (cinfo->token_lockres,DLM_LOCK_EX ); -if (set_bit) -clear_bit_unlock (MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD , &cinfo->state); -if (error) -pr_err ("md-cluster(%s:%d): failed to get EX on TOKEN (%d)\n" , - __func__, __LINE__, error); - -/* Lock the receive sequence */ -mutex_lock (&cinfo->recv_mutex); -return error; -} - -/* lock_comm() -* Sets the MD_CLUSTER_SEND_LOCK bit to lock the send channel. -*/ -static int lock_comm (struct md_cluster_info *cinfo,bool mddev_locked) -{wait_event (cinfo->wait, !test_and_set_bit (MD_CLUSTER_SEND_LOCK , &cinfo->state)); - -return lock_token (cinfo, mddev_locked); + rv =lock_token (cinfo); +if (set_bit) +clear_bit_unlock (MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD , &cinfo->state); +return rv; }static void unlock_comm (struct md_cluster_info *cinfo)
@@ -779,9 +782,11 @@ static int sendmsg(struct md_cluster_inf {int ret; -lock_comm (cinfo, mddev_locked); - ret =__sendmsg (cinfo, cmsg); -unlock_comm (cinfo); + ret =lock_comm (cinfo, mddev_locked); +if (!ret) { + ret =__sendmsg (cinfo, cmsg); +unlock_comm (cinfo); + }return ret; }
@@ -1053,7 +1058,7 @@ static int metadata_update_start(structreturn 0 ; } - ret =lock_token (cinfo,1 ); + ret =lock_token (cinfo);clear_bit_unlock (MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD , &cinfo->state);return ret; }
@@ -1171,7 +1176,10 @@ static void update_size(struct mddev *mdint raid_slot =-1 ;md_update_sb (mddev,1 ); -lock_comm (cinfo,1 ); +if (lock_comm (cinfo,1 )) { +pr_err ("%s: lock_comm failed\n" , __func__); +return ; + }memset (&cmsg,0 ,sizeof (cmsg)); cmsg.type =cpu_to_le32 (METADATA_UPDATED );
@@ -1310,7 +1318,8 @@ static int add_new_disk(struct mddev *md cmsg.type =cpu_to_le32 (NEWDISK );memcpy (cmsg.uuid, uuid,16 ); cmsg.raid_slot =cpu_to_le32 (rdev->desc_nr); -lock_comm (cinfo,1 ); +if (lock_comm (cinfo,1 )) +return -EAGAIN ; ret =__sendmsg (cinfo, &cmsg);if (ret) {unlock_comm (cinfo);
drivers/md/md.c +4 -2
@@ -6537,8 +6537,10 @@ static int hot_remove_disk(struct mddev goto busy; kick_rdev: -if (mddev_is_clustered (mddev)) - md_cluster_ops->remove_disk (mddev, rdev); +if (mddev_is_clustered (mddev)) { +if (md_cluster_ops->remove_disk (mddev, rdev)) + goto busy; + }md_kick_rdev_from_array (rdev);set_bit (MD_SB_CHANGE_DEVS , &mddev->sb_flags);
Greg Kroah-Hartman
maintainerPATCH 234/242 clk: mvebu: a3700: fix the XTAL MODE pin to MPP1_9
In reply to Greg Kroah-HartmanFrom: Terry Zhou <[email protected]>
commit 6f37689cf6b38fff96de52e7f0d3e78f22803ba0 upstream.
There is an error in the current code that the XTAL MODE pin was set to NB MPP1_31 which should be NB MPP1_9. The latch register of NB MPP1_9 has different offset of 0x8.
--- drivers/clk/mvebu/armada-37xx-xtal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/clk/mvebu/armada-37xx-xtal.c +2 -2
@@ -15,8 +15,8 @@#include <linux/platform_device.h> #include <linux/regmap.h> -#define NB_GPIO1_LATCH 0xC -#define XTAL_MODE BIT(31) +#define NB_GPIO1_LATCH 0x8 +#define XTAL_MODE BIT(9)static int armada_3700_xtal_clock_probe (struct platform_device *pdev) {
Greg Kroah-Hartman
maintainerPATCH 235/242 xen-blkback: set ring->xenblkd to NULL after kthread_stop()
In reply to Greg Kroah-HartmanFrom: Pawel Wieczorkiewicz <[email protected]>
commit 1c728719a4da6e654afb9cc047164755072ed7c9 upstream.
When xen_blkif_disconnect() is called, the kernel thread behind the block interface is stopped by calling kthread_stop(ring->xenblkd). The ring->xenblkd thread pointer being non-NULL determines if the thread has been already stopped.
Normally, the thread's function xen_blkif_schedule() sets the ring->xenblkd to NULL, when the thread's main loop ends.
However, when the thread has not been started yet (i.e. wake_up_process() has not been called on it), the xen_blkif_schedule() function would not be called yet.
In such case the kthread_stop() call returns -EINTR and the ring->xenblkd remains dangling.
When this happens, any consecutive call to xen_blkif_disconnect (for example in frontend_changed() callback) leads to a kernel crash in kthread_stop() (e.g. NULL pointer dereference in exit_creds()).
This is XSA-350.
--- drivers/block/xen-blkback/xenbus.c | 1 + 1 file changed, 1 insertion(+)
drivers/block/xen-blkback/xenbus.c +1 -0
@@ -263,6 +263,7 @@ static int xen_blkif_disconnect(struct xif (ring->xenblkd) {kthread_stop (ring->xenblkd); + ring->xenblkd =NULL ;wake_up (&ring->shutdown_wq); }
Greg Kroah-Hartman
maintainerPATCH 236/242 xen/xenbus: Allow watches discard events before queueing
In reply to Greg Kroah-HartmanFrom: SeongJae Park <[email protected]>
commit fed1755b118147721f2c87b37b9d66e62c39b668 upstream.
If handling logics of watch events are slower than the events enqueue logic and the events can be created from the guests, the guests could trigger memory pressure by intensively inducing the events, because it will create a huge number of pending events that exhausting the memory.
Fortunately, some watch events could be ignored, depending on its handler callback. For example, if the callback has interest in only one single path, the watch wouldn't want multiple pending events. Or, some watches could ignore events to same path.
To let such watches to volutarily help avoiding the memory pressure situation, this commit introduces new watch callback, 'will_handle'. If it is not NULL, it will be called for each new event just before enqueuing it. Then, if the callback returns false, the event will be discarded. No watch is using the callback for now, though.
This is part of XSA-349
--- drivers/net/xen-netback/xenbus.c | 4 ++++ drivers/xen/xenbus/xenbus_client.c | 1 + drivers/xen/xenbus/xenbus_xs.c | 5 ++++- include/xen/xenbus.h | 7 +++++++ 4 files changed, 16 insertions(+), 1 deletion(-)
drivers/net/xen-netback/xenbus.c +4 -0
@@ -777,12 +777,14 @@ static int xen_register_credit_watch(strreturn -ENOMEM ;snprintf (node, maxlen,"%s/rate" , dev->nodename); vif->credit_watch.node = node; + vif->credit_watch.will_handle =NULL ; vif->credit_watch.callback = xen_net_rate_changed; err =register_xenbus_watch (&vif->credit_watch);if (err) {pr_err ("Failed to set watcher %s\n" , vif->credit_watch.node);kfree (node); vif->credit_watch.node =NULL ; + vif->credit_watch.will_handle =NULL ; vif->credit_watch.callback =NULL ; }return err;
@@ -829,6 +831,7 @@ static int xen_register_mcast_ctrl_watchsnprintf (node, maxlen,"%s/request-multicast-control" , dev->otherend); vif->mcast_ctrl_watch.node = node; + vif->mcast_ctrl_watch.will_handle =NULL ; vif->mcast_ctrl_watch.callback = xen_mcast_ctrl_changed; err =register_xenbus_watch (&vif->mcast_ctrl_watch);if (err) {
@@ -836,6 +839,7 @@ static int xen_register_mcast_ctrl_watch vif->mcast_ctrl_watch.node);kfree (node); vif->mcast_ctrl_watch.node =NULL ; + vif->mcast_ctrl_watch.will_handle =NULL ; vif->mcast_ctrl_watch.callback =NULL ; }return err;
drivers/xen/xenbus/xenbus_client.c +1 -0
@@ -120,6 +120,7 @@ int xenbus_watch_path(struct xenbus_deviint err; watch->node = path; + watch->will_handle =NULL ; watch->callback = callback; err =register_xenbus_watch (watch);
drivers/xen/xenbus/xenbus_xs.c +4 -1
@@ -700,7 +700,10 @@ int xs_watch_msg(struct xs_watch_event *spin_lock (&watches_lock); event->handle =find_watch (event->token); -if (event->handle !=NULL ) { +if (event->handle !=NULL && + (!event->handle->will_handle || + event->handle->will_handle (event->handle, + event->path, event->token))) {spin_lock (&watch_events_lock);list_add_tail (&event->list, &watch_events);wake_up (&watch_events_waitq);
include/xen/xenbus.h +7 -0
@@ -59,6 +59,13 @@ struct xenbus_watch/* Path being watched. */ const char *node; +/* +* Called just before enqueing new event while a spinlock is held. +* The event will be discarded if this callback returns false. +*/ +bool (*will_handle)(struct xenbus_watch *, +const char *path,const char *token); +/* Callback (executed in a process context with no locks held). */ void (*callback)(struct xenbus_watch *,const char *path,const char *token);
Greg Kroah-Hartman
maintainerPATCH 237/242 xen/xenbus: Add will_handle callback support in xenbus_watch_path()
In reply to Greg Kroah-HartmanFrom: SeongJae Park <[email protected]>
commit 2e85d32b1c865bec703ce0c962221a5e955c52c2 upstream.
Some code does not directly make 'xenbus_watch' object and call 'register_xenbus_watch()' but use 'xenbus_watch_path()' instead. This commit adds support of 'will_handle' callback in the 'xenbus_watch_path()' and it's wrapper, 'xenbus_watch_pathfmt()'.
This is part of XSA-349
--- drivers/block/xen-blkback/xenbus.c | 3 ++- drivers/net/xen-netback/xenbus.c | 2 +- drivers/xen/xen-pciback/xenbus.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 9 +++++++-- drivers/xen/xenbus/xenbus_probe.c | 2 +- include/xen/xenbus.h | 6 +++++- 6 files changed, 17 insertions(+), 7 deletions(-)
drivers/block/xen-blkback/xenbus.c +2 -1
@@ -651,7 +651,8 @@ static int xen_blkbk_probe(struct xenbus/* setup back pointer */ be->blkif->be = be; - err =xenbus_watch_pathfmt (dev, &be->backend_watch, backend_changed, + err =xenbus_watch_pathfmt (dev, &be->backend_watch,NULL , + backend_changed,"%s/%s" , dev->nodename,"physical-device" );if (err) goto fail;
drivers/net/xen-netback/xenbus.c +1 -1
@@ -1043,7 +1043,7 @@ static void connect(struct backend_infoxenvif_carrier_on (be->vif);unregister_hotplug_status_watch (be); - err =xenbus_watch_pathfmt (dev, &be->hotplug_status_watch, + err =xenbus_watch_pathfmt (dev, &be->hotplug_status_watch,NULL , hotplug_status_changed,"%s/%s" , dev->nodename,"hotplug-status" );if (!err)
drivers/xen/xen-pciback/xenbus.c +1 -1
@@ -688,7 +688,7 @@ static int xen_pcibk_xenbus_probe(struct/* watch the backend node for backend configuration information */ err =xenbus_watch_path (dev, dev->nodename, &pdev->be_watch, - xen_pcibk_be_watch); +NULL , xen_pcibk_be_watch);if (err) goto out;
drivers/xen/xenbus/xenbus_client.c +7 -2
@@ -114,19 +114,22 @@ EXPORT_SYMBOL_GPL(xenbus_strstate);*/ int xenbus_watch_path (struct xenbus_device *dev,const char *path,struct xenbus_watch *watch, +bool (*will_handle)(struct xenbus_watch *, +const char *,const char *),void (*callback)(struct xenbus_watch *,const char *,const char *)) {int err; watch->node = path; - watch->will_handle =NULL ; + watch->will_handle = will_handle; watch->callback = callback; err =register_xenbus_watch (watch);if (err) { watch->node =NULL ; + watch->will_handle =NULL ; watch->callback =NULL ;xenbus_dev_fatal (dev, err,"adding watch on %s" , path); }
@@ -153,6 +156,8 @@ EXPORT_SYMBOL_GPL(xenbus_watch_path);*/ int xenbus_watch_pathfmt (struct xenbus_device *dev,struct xenbus_watch *watch, +bool (*will_handle)(struct xenbus_watch *, +const char *,const char *),void (*callback)(struct xenbus_watch *,const char *,const char *),const char *pathfmt, ...)
@@ -169,7 +174,7 @@ int xenbus_watch_pathfmt(struct xenbus_dxenbus_dev_fatal (dev, -ENOMEM ,"allocating path for watch" );return -ENOMEM ; } - err =xenbus_watch_path (dev, path, watch, callback); + err =xenbus_watch_path (dev, path, watch, will_handle, callback);if (err)kfree (path);
drivers/xen/xenbus/xenbus_probe.c +1 -1
@@ -136,7 +136,7 @@ static int watch_otherend(struct xenbus_ container_of(dev->dev.bus, struct xen_bus_type, bus);return xenbus_watch_pathfmt (dev, &dev->otherend_watch, - bus->otherend_changed, +NULL , bus->otherend_changed,"%s/%s" , dev->otherend,"state" ); }
include/xen/xenbus.h +5 -1
@@ -199,10 +199,14 @@ void xenbus_probe(struct work_struct *);int xenbus_watch_path (struct xenbus_device *dev,const char *path,struct xenbus_watch *watch, +bool (*will_handle)(struct xenbus_watch *, +const char *,const char *),void (*callback)(struct xenbus_watch *,const char *,const char *)); -__printf(4, 5) +__printf(5, 6)int xenbus_watch_pathfmt (struct xenbus_device *dev,struct xenbus_watch *watch, +bool (*will_handle)(struct xenbus_watch *, +const char *,const char *),void (*callback)(struct xenbus_watch *,const char *,const char *),const char *pathfmt, ...);
Greg Kroah-Hartman
maintainerPATCH 238/242 xen/xenbus/xen_bus_type: Support will_handle watch callback
In reply to Greg Kroah-HartmanFrom: SeongJae Park <[email protected]>
commit be987200fbaceaef340872841d4f7af2c5ee8dc3 upstream.
This commit adds support of the 'will_handle' watch callback for 'xen_bus_type' users.
This is part of XSA-349
--- drivers/xen/xenbus/xenbus.h | 2 ++ drivers/xen/xenbus/xenbus_probe.c | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-)
drivers/xen/xenbus/xenbus.h +2 -0
@@ -44,6 +44,8 @@ struct xen_bus_type {int (*get_bus_id)(char bus_id[XEN_BUS_ID_SIZE ],const char *nodename);int (*probe)(struct xen_bus_type *bus,const char *type,const char *dir); +bool (*otherend_will_handle)(struct xenbus_watch *watch, +const char *path,const char *token);void (*otherend_changed)(struct xenbus_watch *watch,const char *path,const char *token);struct bus_type bus;
drivers/xen/xenbus/xenbus_probe.c +2 -1
@@ -136,7 +136,8 @@ static int watch_otherend(struct xenbus_ container_of(dev->dev.bus, struct xen_bus_type, bus);return xenbus_watch_pathfmt (dev, &dev->otherend_watch, -NULL , bus->otherend_changed, + bus->otherend_will_handle, + bus->otherend_changed,"%s/%s" , dev->otherend,"state" ); }
Greg Kroah-Hartman
maintainerPATCH 239/242 xen/xenbus: Count pending messages for each watch
In reply to Greg Kroah-HartmanFrom: SeongJae Park <[email protected]>
commit 3dc86ca6b4c8cfcba9da7996189d1b5a358a94fc upstream.
This commit adds a counter of pending messages for each watch in the struct. It is used to skip unnecessary pending messages lookup in 'unregister_xenbus_watch()'. It could also be used in 'will_handle' callback.
This is part of XSA-349
--- drivers/xen/xenbus/xenbus_xs.c | 29 ++++++++++++++++++----------- include/xen/xenbus.h | 2 ++ 2 files changed, 20 insertions(+), 11 deletions(-)
drivers/xen/xenbus/xenbus_xs.c +18 -11
@@ -706,6 +706,7 @@ int xs_watch_msg(struct xs_watch_event * event->path, event->token))) {spin_lock (&watch_events_lock);list_add_tail (&event->list, &watch_events); + event->handle->nr_pending++;wake_up (&watch_events_waitq);spin_unlock (&watch_events_lock); } else
@@ -763,6 +764,8 @@ int register_xenbus_watch(struct xenbus_sprintf (token,"%lX" , (long )watch); + watch->nr_pending =0 ; +down_read (&xs_watch_rwsem);spin_lock (&watches_lock);
@@ -812,11 +815,14 @@ void unregister_xenbus_watch(struct xenb/* Cancel pending watch events. */ spin_lock (&watch_events_lock); -list_for_each_entry_safe (event, tmp, &watch_events, list) { -if (event->handle != watch) -continue ; -list_del (&event->list); -kfree (event); +if (watch->nr_pending) { +list_for_each_entry_safe (event, tmp, &watch_events, list) { +if (event->handle != watch) +continue ; +list_del (&event->list); +kfree (event); + } + watch->nr_pending =0 ; }spin_unlock (&watch_events_lock);
@@ -863,7 +869,6 @@ void xs_suspend_cancel(void)static int xenwatch_thread (void *unused) { -struct list_head *ent;struct xs_watch_event *event; xenwatch_pid = current->pid;
@@ -878,13 +883,15 @@ static int xenwatch_thread(void *unused)mutex_lock (&xenwatch_mutex);spin_lock (&watch_events_lock); - ent = watch_events.next; -if (ent != &watch_events) -list_del (ent); + event =list_first_entry_or_null (&watch_events, + struct xs_watch_event, list); +if (event) { +list_del (&event->list); + event->handle->nr_pending--; + }spin_unlock (&watch_events_lock); -if (ent != &watch_events) { - event = list_entry(ent, struct xs_watch_event, list); +if (event) { event->handle->callback (event->handle, event->path, event->token);kfree (event);
include/xen/xenbus.h +2 -0
@@ -59,6 +59,8 @@ struct xenbus_watch/* Path being watched. */ const char *node; +unsigned int nr_pending; +/* * Called just before enqueing new event while a spinlock is held. * The event will be discarded if this callback returns false.
Greg Kroah-Hartman
maintainerPATCH 240/242 xenbus/xenbus_backend: Disallow pending watch messages
In reply to Greg Kroah-HartmanFrom: SeongJae Park <[email protected]>
commit 9996bd494794a2fe393e97e7a982388c6249aa76 upstream.
'xenbus_backend' watches 'state' of devices, which is writable by guests. Hence, if guests intensively updates it, dom0 will have lots of pending events that exhausting memory of dom0. In other words, guests can trigger dom0 memory pressure. This is known as XSA-349. However, the watch callback of it, 'frontend_changed()', reads only 'state', so doesn't need to have the pending events.
To avoid the problem, this commit disallows pending watch messages for 'xenbus_backend' using the 'will_handle()' watch callback.
This is part of XSA-349
--- drivers/xen/xenbus/xenbus_probe_backend.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/xen/xenbus/xenbus_probe_backend.c +7 -0
@@ -180,6 +180,12 @@ static int xenbus_probe_backend(struct xreturn err; } +static bool frontend_will_handle (struct xenbus_watch *watch, +const char *path,const char *token) +{ +return watch->nr_pending ==0 ; +} +static void frontend_changed (struct xenbus_watch *watch,const char *path,const char *token) {
@@ -191,6 +197,7 @@ static struct xen_bus_type xenbus_backen .levels = 3, /* backend/type/<frontend>/<id> */ .get_bus_id = backend_bus_id, .probe = xenbus_probe_backend, + .otherend_will_handle = frontend_will_handle, .otherend_changed = frontend_changed, .bus = { .name = "xen-backend",
Greg Kroah-Hartman
maintainerPATCH 241/242 libnvdimm/namespace: Fix reaping of invalidated block-window-namespace labels
In reply to Greg Kroah-HartmanFrom: Dan Williams <[email protected]>
commit 2dd2a1740ee19cd2636d247276cf27bfa434b0e2 upstream.
A recent change to ndctl to attempt to reconfigure namespaces in place uncovered a label accounting problem in block-window-type namespaces. The ndctl "create.sh" test is able to trigger this signature:
WARNING: CPU: 34 PID: 9167 at drivers/nvdimm/label.c:1100 __blk_label_update+0x9a3/0xbc0 [libnvdimm] [..] RIP: 0010:__blk_label_update+0x9a3/0xbc0 [libnvdimm] [..] Call Trace: uuid_store+0x21b/0x2f0 [libnvdimm] kernfs_fop_write+0xcf/0x1c0 vfs_write+0xcc/0x380 ksys_write+0x68/0xe0
When allocated capacity for a namespace is renamed (new UUID) the labels with the old UUID need to be deleted. The ndctl behavior to always destroy namespaces on reconfiguration hid this problem.
The immediate impact of this bug is limited since block-window-type namespaces only seem to exist in the specification and not in any shipping products. However, the label handling code is being reused for other technologies like CXL region labels, so there is a benefit to making sure both vertical labels sets (block-window) and horizontal label sets (pmem) have a functional reference implementation in libnvdimm.
--- drivers/nvdimm/label.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/nvdimm/label.c +9 -0
@@ -852,6 +852,15 @@ static int __blk_label_update(struct nd_ } } +/* release slots associated with any invalidated UUIDs */ +mutex_lock (&nd_mapping->lock); +list_for_each_entry_safe (label_ent, e, &nd_mapping->labels, list) +if (test_and_clear_bit (ND_LABEL_REAP , &label_ent->flags)) { +reap_victim (nd_mapping, label_ent); +list_move (&label_ent->list, &list); + } +mutex_unlock (&nd_mapping->lock); +/* * Find the resource associated with the first label in the set * per the v1.2 namespace specification.
Greg Kroah-Hartman
maintainerPATCH 242/242 PCI: Fix pci_slot_release() NULL pointer dereference
In reply to Greg Kroah-HartmanFrom: Jubin Zhong <[email protected]>
commit 4684709bf81a2d98152ed6b610e3d5c403f9bced upstream.
If kobject_init_and_add() fails, pci_slot_release() is called to delete slot->list from parent->slots. But slot->list hasn't been initialized yet, so we dereference a NULL pointer:
Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... CPU: 10 PID: 1 Comm: swapper/0 Not tainted 4.4.240 #197 task: ffffeb398a45ef10 task.stack: ffffeb398a470000 PC is at __list_del_entry_valid+0x5c/0xb0 LR is at pci_slot_release+0x84/0xe4 ... __list_del_entry_valid+0x5c/0xb0 pci_slot_release+0x84/0xe4 kobject_put+0x184/0x1c4 pci_create_slot+0x17c/0x1b4 __pci_hp_initialize+0x68/0xa4 pciehp_probe+0x1a4/0x2fc pcie_port_probe_service+0x58/0x84 driver_probe_device+0x320/0x470
Initialize slot->list before calling kobject_init_and_add() to avoid this.
--- drivers/pci/slot.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/pci/slot.c +3 -3
@@ -307,6 +307,9 @@ placeholder: goto err; } +INIT_LIST_HEAD (&slot->list); +list_add (&slot->list, &parent->slots); + err =kobject_init_and_add (&slot->kobj, &pci_slot_ktype,NULL ,"%s" , slot_name);if (err) {
@@ -314,9 +317,6 @@ placeholder: goto err; } -INIT_LIST_HEAD (&slot->list); -list_add (&slot->list, &parent->slots); -down_read (&pci_bus_sem);list_for_each_entry (dev, &parent->devices, bus_list)if (PCI_SLOT (dev->devfn) == slot_nr)
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.213 release. There are 242 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 30 Dec 2020 12:48:23 +0000. Anything received after that time might be too late.
Build results:
total: 168 pass: 168 fail: 0 Qemu test results: total: 404 pass: 404 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.213 release. There are 242 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 30 Dec 2020 12:48:23 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.213-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
30 tests: 30 pass, 0 failLinux version: 4.14.213-rc1-gcaadb02efa3e
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Jon
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.213 release. There are 242 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 30 Dec 2020 12:48:23 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.213-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.14.213-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: caadb02efa3e1be5616bc1cae5b2a4a628b4730c
git describe: v4.14.212-243-gcaadb02efa3e
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.212-243-gcaadb02efa3e
No regressions (compared to build v4.14.212)
No fixes (compared to build v4.14.212)
Ran 38814 total tests in the following environments and test suites.
Environments
--------------
- arm
- arm64
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- mips
- qemu-arm64-kasan
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- sparc
- x15 - arm
- x86_64
- x86-kasan
Test Suites
-----------
* build
* linux-log-parser
* install-android-platform-tools-r2600
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* perf
* fwts
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-sched-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* ltp-controllers-tests
* ltp-open-posix-tests
* v4l2-compliance
* kvm-unit-tests
* rcutorture
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org