arm64: debug: unmask PSTATE.D earlier
Subsystems (3)
A message that is not in the archive (sent off-list or not yet received): CGME20160818140229uscas1p28936a684c22cfb777077f1c973fad437@uscas1p2.samsung.com
A message that is not in the archive (sent off-list or not yet received): [email protected]
Greg Kroah-Hartman
maintainerPATCH 1/138 usb: gadget: avoid exposing kernel stack
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heinrich Schuchardt <[email protected]>
commit ffeee83aa0461992e8a99a59db2df31933e60362 upstream.
Function in_rq_cur copies random bytes from the stack. Zero the memory instead.
--- drivers/usb/gadget/function/f_uac2.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/gadget/function/f_uac2.c +1 -0
@@ -1291,6 +1291,7 @@ in_rq_cur(struct usb_function *fn, constif (control_selector ==UAC2_CS_CONTROL_SAM_FREQ ) {struct cntrl_cur_lay3 c; +memset (&c,0 ,sizeof (struct cntrl_cur_lay3 ));if (entity_id ==USB_IN_CLK_ID ) c.dCUR = p_srate;
Greg Kroah-Hartman
maintainerPATCH 2/138 usb: f_fs: off by one bug in _ffs_func_bind()
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 0015f9156092d07b3ec06d37d014328419d5832e upstream.
This loop is supposed to set all the .num[] values to -1 but it's off by one so it skips the first element and sets one element past the end of the array.
I've cleaned up the loop a little as well.
--- drivers/usb/gadget/function/f_fs.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
drivers/usb/gadget/function/f_fs.c +4 -6
@@ -2740,6 +2740,7 @@ static int _ffs_func_bind(struct usb_con func->ffs->ss_descs_count;int fs_len, hs_len, ss_len, ret, i; +struct ffs_ep *eps_ptr;/* Make it a single chunk, less management later on */ vla_group (d);
@@ -2788,12 +2789,9 @@ static int _ffs_func_bind(struct usb_con ffs->raw_descs_length);memset (vla_ptr (vlabuf, d, inums),0xff , d_inums__sz); -for (ret = ffs->eps_count; ret; --ret) { -struct ffs_ep *ptr; - - ptr =vla_ptr (vlabuf, d, eps); - ptr[ret].num =-1 ; - } + eps_ptr =vla_ptr (vlabuf, d, eps); +for (i =0 ; i < ffs->eps_count; i++) + eps_ptr[i].num =-1 ;/* Save pointers * d_eps == vlabuf, func->eps used to kfree vlabuf later
Greg Kroah-Hartman
maintainerPATCH 4/138 usb: quirks: Add no-lpm quirk for Elan
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joseph Salisbury <[email protected]>
commit 25b1f9acc452209ae0fcc8c1332be852b5c52f53 upstream.
As reported in BugLink, this device has an issue with Linux Power Management so adding a quirk. This quirk was reccomended by Alan Stern:
http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05590.html
--- drivers/usb/core/quirks.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/core/quirks.c +3 -0
@@ -128,6 +128,9 @@ static const struct usb_device_id usb_qu { USB_DEVICE(0x04f3, 0x016f), .driver_info = USB_QUIRK_DEVICE_QUALIFIER }, + { USB_DEVICE(0x04f3, 0x0381), .driver_info = + USB_QUIRK_NO_LPM }, + { USB_DEVICE(0x04f3, 0x21b8), .driver_info = USB_QUIRK_DEVICE_QUALIFIER },
Greg Kroah-Hartman
maintainerPATCH 10/138 arm64: debug: unmask PSTATE.D earlier
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit 2ce39ad15182604beb6c8fa8bed5e46b59fd1082 upstream.
Clearing PSTATE.D is one of the requirements for generating a debug exception. The arm64 booting protocol requires that PSTATE.D is set, since many of the debug registers (for example, the hw_breakpoint registers) are UNKNOWN out of reset and could potentially generate spurious, fatal debug exceptions in early boot code if PSTATE.D was clear. Once the debug registers have been safely initialised, PSTATE.D is cleared, however this is currently broken for two reasons:
(1) The boot CPU clears PSTATE.D in a postcore_initcall and secondary CPUs clear PSTATE.D in secondary_start_kernel. Since the initcall runs after SMP (and the scheduler) have been initialised, there is no guarantee that it is actually running on the boot CPU. In this case, the boot CPU is left with PSTATE.D set and is not capable of generating debug exceptions.
(2) In a preemptible kernel, we may explicitly schedule on the IRQ return path to EL1. If an IRQ occurs with PSTATE.D set in the idle thread, then we may schedule the kthread_init thread, run the postcore_initcall to clear PSTATE.D and then context switch back to the idle thread before returning from the IRQ. The exception return path will then restore PSTATE.D from the stack, and set it again.
This patch fixes the problem by moving the clearing of PSTATE.D earlier to proc.S. This has the desirable effect of clearing it in one place for all CPUs, long before we have to worry about the scheduler or any exception handling. We ensure that the previous reset of MDSCR_EL1 has completed before unmasking the exception, so that any spurious exceptions resulting from UNKNOWN debug registers are not generated.
Without this patch applied, the kprobes selftests have been seen to fail under KVM, where we end up attempting to step the OOL instruction buffer with PSTATE.D set and therefore fail to complete the step.
--- arch/arm64/kernel/debug-monitors.c | 1 - arch/arm64/kernel/smp.c | 1 - arch/arm64/mm/proc.S | 2 ++ 3 files changed, 2 insertions(+), 2 deletions(-)
arch/arm64/kernel/debug-monitors.c +0 -1
@@ -152,7 +152,6 @@ static int debug_monitors_init(void)/* Clear the OS lock. */ on_each_cpu (clear_os_lock,NULL ,1 );isb (); -local_dbg_enable ();/* Register hotplug handler. */ __register_cpu_notifier (&os_lock_nb);
arch/arm64/kernel/smp.c +0 -1
@@ -188,7 +188,6 @@ asmlinkage void secondary_start_kernel(vset_cpu_online (cpu, true);complete (&cpu_running); -local_dbg_enable ();local_irq_enable ();local_async_enable ();
arch/arm64/mm/proc.S +2 -0
@@ -156,6 +156,8 @@ ENTRY(__cpu_setup) msr cpacr_el1, x0 // Enable FP/ASIMD mov x0, #1 << 12 // Reset mdscr_el1 and disable msr mdscr_el1, x0 // access to the DCC from EL0 + isb // Unmask debug exceptions now, + enable_dbg // since this is per-cpu reset_pmuserenr_el0 x0 // Disable PMU access from EL0 /* * Memory region attributes for LPAE:
Greg Kroah-Hartman
maintainerPATCH 12/138 tty: serial: msm: Dont read off end of tx fifo
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
commit 30acf549ca1e81859a67590ab9ecfce3d1050a0b upstream.
For dm uarts in pio mode tx data is transferred to the fifo register 4 bytes at a time, but care is not taken when these 4 bytes spans the end of the xmit buffer so the loop might read up to 3 bytes past the buffer and then skip the actual data at the beginning of the buffer.
Fix this by, analogous to the DMA case, make sure the chunk doesn't wrap the xmit buffer.
--- drivers/tty/serial/msm_serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/serial/msm_serial.c +1 -1
@@ -726,7 +726,7 @@ static void msm_handle_tx(struct uart_poreturn ; } - pio_count =CIRC_CNT (xmit->head, xmit->tail,UART_XMIT_SIZE ); + pio_count =CIRC_CNT_TO_END (xmit->head, xmit->tail,UART_XMIT_SIZE ); dma_count =CIRC_CNT_TO_END (xmit->head, xmit->tail,UART_XMIT_SIZE ); dma_min =1 ;/* Always DMA */
Greg Kroah-Hartman
maintainerPATCH 1/4 MIPS: KVM: Fix mapped fault broken commpage handling
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit c604cffa93478f8888bec62b23d6073dad03d43a upstream.
kvm_mips_handle_mapped_seg_tlb_fault() appears to map the guest page at virtual address 0 to PFN 0 if the guest has created its own mapping there. The intention is unclear, but it may have been an attempt to protect the zero page from being mapped to anything but the comm page in code paths you wouldn't expect from genuine commpage accesses (guest kernel mode cache instructions on that address, hitting trapping instructions when executing from that address with a coincidental TLB eviction during the KVM handling, and guest user mode accesses to that address).
Fix this to check for mappings exactly at KVM_GUEST_COMMPAGE_ADDR (it may not be at address 0 since commit 42aa12e74e91 ("MIPS: KVM: Move commpage so 0x0 is unmapped")), and set the corresponding EntryLo to be interpreted as 0 (invalid).
--- arch/mips/kvm/tlb.c | 45 ++++++++++++++++++++++++++------------------- 1 file changed, 26 insertions(+), 19 deletions(-)
arch/mips/kvm/tlb.c +26 -19
@@ -361,24 +361,31 @@ int kvm_mips_handle_mapped_seg_tlb_faultunsigned long entryhi =0 , entrylo0 =0 , entrylo1 =0 ;struct kvm *kvm = vcpu->kvm;pfn_t pfn0, pfn1; +long tlb_lo[2 ]; -if ((tlb->tlb_hi &VPN2_MASK ) ==0 ) { - pfn0 =0 ; - pfn1 =0 ; - }else { -if (kvm_mips_map_page (kvm,mips3_tlbpfn_to_paddr (tlb->tlb_lo0) - >>PAGE_SHIFT ) <0 ) -return -1 ; - -if (kvm_mips_map_page (kvm,mips3_tlbpfn_to_paddr (tlb->tlb_lo1) - >>PAGE_SHIFT ) <0 ) -return -1 ; - - pfn0 = kvm->arch.guest_pmap[mips3_tlbpfn_to_paddr (tlb->tlb_lo0) - >>PAGE_SHIFT ]; - pfn1 = kvm->arch.guest_pmap[mips3_tlbpfn_to_paddr (tlb->tlb_lo1) - >>PAGE_SHIFT ]; - } + tlb_lo[0 ] = tlb->tlb_lo0; + tlb_lo[1 ] = tlb->tlb_lo1; + +/* +* The commpage address must not be mapped to anything else if the guest +* TLB contains entries nearby, or commpage accesses will break. +*/ +if (!((tlb->tlb_hi ^KVM_GUEST_COMMPAGE_ADDR ) & +VPN2_MASK & (PAGE_MASK <<1 ))) + tlb_lo[(KVM_GUEST_COMMPAGE_ADDR >>PAGE_SHIFT ) &1 ] =0 ; + +if (kvm_mips_map_page (kvm,mips3_tlbpfn_to_paddr (tlb_lo[0 ]) + >>PAGE_SHIFT ) <0 ) +return -1 ; + +if (kvm_mips_map_page (kvm,mips3_tlbpfn_to_paddr (tlb_lo[1 ]) + >>PAGE_SHIFT ) <0 ) +return -1 ; + + pfn0 = kvm->arch.guest_pmap[mips3_tlbpfn_to_paddr (tlb_lo[0 ]) + >>PAGE_SHIFT ]; + pfn1 = kvm->arch.guest_pmap[mips3_tlbpfn_to_paddr (tlb_lo[1 ]) + >>PAGE_SHIFT ];if (hpa0) *hpa0 = pfn0 <<PAGE_SHIFT ;
@@ -391,9 +398,9 @@ int kvm_mips_handle_mapped_seg_tlb_fault kvm_mips_get_kernel_asid(vcpu) : kvm_mips_get_user_asid(vcpu)); entrylo0 =mips3_paddr_to_tlbpfn (pfn0 <<PAGE_SHIFT ) | (0x3 <<3 ) | - (tlb->tlb_lo0 &MIPS3_PG_D ) | (tlb->tlb_lo0 &MIPS3_PG_V ); + (tlb_lo[0 ] &MIPS3_PG_D ) | (tlb_lo[0 ] &MIPS3_PG_V ); entrylo1 =mips3_paddr_to_tlbpfn (pfn1 <<PAGE_SHIFT ) | (0x3 <<3 ) | - (tlb->tlb_lo1 &MIPS3_PG_D ) | (tlb->tlb_lo1 &MIPS3_PG_V ); + (tlb_lo[1 ] &MIPS3_PG_D ) | (tlb_lo[1 ] &MIPS3_PG_V );kvm_debug ("@ %#lx tlb_lo0: 0x%08lx tlb_lo1: 0x%08lx\n" , vcpu->arch.pc, tlb->tlb_lo0, tlb->tlb_lo1);
Greg Kroah-Hartman
maintainerPATCH 2/4 MIPS: KVM: Add missing gfn range check
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit 8985d50382359e5bf118fdbefc859d0dbf6cebc7 upstream.
kvm_mips_handle_mapped_seg_tlb_fault() calculates the guest frame number based on the guest TLB EntryLo values, however it is not range checked to ensure it lies within the guest_pmap. If the physical memory the guest refers to is out of range then dump the guest TLB and emit an internal error.
--- arch/mips/kvm/tlb.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-)
arch/mips/kvm/tlb.c +15 -8
@@ -361,6 +361,7 @@ int kvm_mips_handle_mapped_seg_tlb_faultunsigned long entryhi =0 , entrylo0 =0 , entrylo1 =0 ;struct kvm *kvm = vcpu->kvm;pfn_t pfn0, pfn1; +gfn_t gfn0, gfn1;long tlb_lo[2 ]; tlb_lo[0 ] = tlb->tlb_lo0;
@@ -374,18 +375,24 @@ int kvm_mips_handle_mapped_seg_tlb_fault VPN2_MASK & (PAGE_MASK << 1))) tlb_lo[(KVM_GUEST_COMMPAGE_ADDR >>PAGE_SHIFT ) &1 ] =0 ; -if (kvm_mips_map_page (kvm,mips3_tlbpfn_to_paddr (tlb_lo[0 ]) - >>PAGE_SHIFT ) <0 ) + gfn0 =mips3_tlbpfn_to_paddr (tlb_lo[0 ]) >>PAGE_SHIFT ; + gfn1 =mips3_tlbpfn_to_paddr (tlb_lo[1 ]) >>PAGE_SHIFT ; +if (gfn0 >= kvm->arch.guest_pmap_npages || + gfn1 >= kvm->arch.guest_pmap_npages) { +kvm_err ("%s: Invalid gfn: [%#llx, %#llx], EHi: %#lx\n" , + __func__, gfn0, gfn1, tlb->tlb_hi); +kvm_mips_dump_guest_tlbs (vcpu);return -1 ; + } -if (kvm_mips_map_page (kvm,mips3_tlbpfn_to_paddr (tlb_lo[1 ]) - >>PAGE_SHIFT ) <0 ) +if (kvm_mips_map_page (kvm, gfn0) <0 )return -1 ; - pfn0 = kvm->arch.guest_pmap[mips3_tlbpfn_to_paddr (tlb_lo[0 ]) - >>PAGE_SHIFT ]; - pfn1 = kvm->arch.guest_pmap[mips3_tlbpfn_to_paddr (tlb_lo[1 ]) - >>PAGE_SHIFT ]; +if (kvm_mips_map_page (kvm, gfn1) <0 ) +return -1 ; + + pfn0 = kvm->arch.guest_pmap[gfn0]; + pfn1 = kvm->arch.guest_pmap[gfn1];if (hpa0) *hpa0 = pfn0 <<PAGE_SHIFT ;
Greg Kroah-Hartman
maintainerPATCH 3/4 MIPS: KVM: Fix gfn range check in kseg0 tlb faults
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit 0741f52d1b980dbeb290afe67d88fc2928edd8ab upstream.
Two consecutive gfns are loaded into host TLB, so ensure the range check isn't off by one if guest_pmap_npages is odd.
--- arch/mips/kvm/tlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/kvm/tlb.c +1 -1
@@ -276,7 +276,7 @@ int kvm_mips_handle_kseg0_tlb_fault(unsi } gfn = (KVM_GUEST_CPHYSADDR (badvaddr) >>PAGE_SHIFT ); -if (gfn >= kvm->arch.guest_pmap_npages) { +if ((gfn |1 ) >= kvm->arch.guest_pmap_npages) {kvm_err ("%s: Invalid gfn: %#llx, BadVaddr: %#lx\n" , __func__, gfn, badvaddr);kvm_mips_dump_host_tlbs ();
Greg Kroah-Hartman
maintainerPATCH 4/4 MIPS: KVM: Propagate kseg0/mapped tlb fault errors
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit 9b731bcfdec4c159ad2e4312e25d69221709b96a upstream.
Propagate errors from kvm_mips_handle_kseg0_tlb_fault() and kvm_mips_handle_mapped_seg_tlb_fault(), usually triggering an internal error since they normally indicate the guest accessed bad physical memory or the commpage in an unexpected way.
--- arch/mips/kvm/emulate.c | 40 ++++++++++++++++++++++++++++------------ arch/mips/kvm/tlb.c | 14 ++++++++++---- 2 files changed, 38 insertions(+), 16 deletions(-)
arch/mips/kvm/emulate.c +28 -12
@@ -1629,8 +1629,14 @@ enum emulation_result kvm_mips_emulate_cpreempt_disable ();if (KVM_GUEST_KSEGX (va) ==KVM_GUEST_KSEG0 ) { -if (kvm_mips_host_tlb_lookup (vcpu, va) <0 ) -kvm_mips_handle_kseg0_tlb_fault (va, vcpu); +if (kvm_mips_host_tlb_lookup (vcpu, va) <0 && +kvm_mips_handle_kseg0_tlb_fault (va, vcpu)) { +kvm_err ("%s: handling mapped kseg0 tlb fault for %lx, vcpu: %p, ASID: %#lx\n" , + __func__, va, vcpu,read_c0_entryhi ()); + er =EMULATE_FAIL ; +preempt_enable (); + goto done; + } }else if ((KVM_GUEST_KSEGX (va) <KVM_GUEST_KSEG0 ) ||KVM_GUEST_KSEGX (va) ==KVM_GUEST_KSEG23 ) {int index;
@@ -1665,14 +1671,19 @@ enum emulation_result kvm_mips_emulate_c run, vcpu);preempt_enable (); goto dont_update_pc; - }else { -/* -* We fault an entry from the guest tlb to the -* shadow host TLB -*/ -kvm_mips_handle_mapped_seg_tlb_fault (vcpu, tlb, -NULL , -NULL ); + } +/* +* We fault an entry from the guest tlb to the +* shadow host TLB +*/ +if (kvm_mips_handle_mapped_seg_tlb_fault (vcpu, tlb, +NULL ,NULL )) { +kvm_err ("%s: handling mapped seg tlb fault for %lx, index: %u, vcpu: %p, ASID: %#lx\n" , + __func__, va, index, vcpu, +read_c0_entryhi ()); + er =EMULATE_FAIL ; +preempt_enable (); + goto done; } } }else {
@@ -2633,8 +2644,13 @@ enum emulation_result kvm_mips_handle_tl* OK we have a Guest TLB entry, now inject it into the * shadow host TLB */ -kvm_mips_handle_mapped_seg_tlb_fault (vcpu, tlb,NULL , -NULL ); +if (kvm_mips_handle_mapped_seg_tlb_fault (vcpu, tlb, +NULL ,NULL )) { +kvm_err ("%s: handling mapped seg tlb fault for %lx, index: %u, vcpu: %p, ASID: %#lx\n" , + __func__, va, index, vcpu, +read_c0_entryhi ()); + er =EMULATE_FAIL ; + } } }
arch/mips/kvm/tlb.c +10 -4
@@ -808,10 +808,16 @@ uint32_t kvm_get_inst(uint32_t *opc, strlocal_irq_restore (flags);return KVM_INVALID_INST ; } -kvm_mips_handle_mapped_seg_tlb_fault (vcpu, - &vcpu->arch. - guest_tlb[index], -NULL ,NULL ); +if (kvm_mips_handle_mapped_seg_tlb_fault (vcpu, + &vcpu->arch.guest_tlb[index], +NULL ,NULL )) { +kvm_err ("%s: handling mapped seg tlb fault failed for %p, index: %u, vcpu: %p, ASID: %#lx\n" , + __func__, opc, index, vcpu, +read_c0_entryhi ()); +kvm_mips_dump_guest_tlbs (vcpu); +local_irq_restore (flags); +return KVM_INVALID_INST ; + } inst = *(opc); }local_irq_restore (flags);
Greg Kroah-Hartman
maintainerPATCH 14/138 tty/serial: atmel: fix RS485 half duplex with DMA
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Belloni <[email protected]>
commit 0058f0871efe7b01c6f2b3046c68196ab73e96da upstream.
When using DMA, half duplex doesn't work properly because rx is not stopped before starting tx. Ensure we call atmel_stop_rx() in the DMA case.
--- drivers/tty/serial/atmel_serial.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/tty/serial/atmel_serial.c +8 -6
@@ -485,19 +485,21 @@ static void atmel_start_tx(struct uart_p {struct atmel_uart_port *atmel_port =to_atmel_uart_port (port); -if (atmel_use_pdc_tx (port)) { -if (atmel_uart_readl (port,ATMEL_PDC_PTSR ) &ATMEL_PDC_TXTEN ) -/* The transmitter is already running. Yes, we -really need this.*/ -return ; +if (atmel_use_pdc_tx (port) && (atmel_uart_readl (port,ATMEL_PDC_PTSR ) + &ATMEL_PDC_TXTEN )) +/* The transmitter is already running. Yes, we +really need this.*/ +return ; +if (atmel_use_pdc_tx (port) ||atmel_use_dma_tx (port))if ((port->rs485.flags &SER_RS485_ENABLED ) && !(port->rs485.flags &SER_RS485_RX_DURING_TX ))atmel_stop_rx (port); +if (atmel_use_pdc_tx (port))/* re-enable PDC transmit */ atmel_uart_writel (port,ATMEL_PDC_PTCR ,ATMEL_PDC_TXTEN ); - } +/* Enable interrupts */ atmel_uart_writel (port,ATMEL_US_IER , atmel_port->tx_done_mask); }
Greg Kroah-Hartman
maintainerPATCH 15/138 gpio: pca953x: Fix NBANK calculation for PCA9536
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vignesh R <[email protected]>
commit a246b8198f776a16d1d3a3bbfc2d437bad766b29 upstream.
NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and hence results in 0 banks for PCA9536 which has just 4 gpios. This is wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in NBANK().
--- drivers/gpio/gpio-pca953x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpio-pca953x.c +1 -1
@@ -86,7 +86,7 @@ MODULE_DEVICE_TABLE(acpi, pca953x_acpi_i#define MAX_BANK 5#define BANK_SZ 8 -#define NBANK (chip) (chip->gpio_chip.ngpio / BANK_SZ) +#define NBANK (chip) DIV_ROUND_UP(chip->gpio_chip.ngpio, BANK_SZ)struct pca953x_chip {unsigned gpio_start;
Greg Kroah-Hartman
maintainerPATCH 16/138 gpio: intel-mid: Remove potentially harmful code
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
commit 3dbd3212f81b2b410a34a922055e2da792864829 upstream.
The commit d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support") doesn't look at all as a proper support for Intel Merrifield and I dare to say that it distorts the behaviour of the hardware.
The register map is different on Intel Merrifield, i.e. only 6 out of 8 register have the same purpose but none of them has same location in the address space. The current case potentially harmful to existing hardware since it's poking registers on wrong offsets and may set some pin to be GPIO output when connected hardware doesn't expect such.
Besides the above GPIO and pinctrl on Intel Merrifield have been located in different IP blocks. The functionality has been extended as well, i.e. added support of level interrupts, special registers for wake capable sources and thus, in my opinion, requires a completele separate driver.
If someone wondering the existing gpio-intel-mid.c would be converted to actual pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do that.
--- drivers/gpio/gpio-intel-mid.c | 19 ------------------- 1 file changed, 19 deletions(-)
drivers/gpio/gpio-intel-mid.c +0 -19
@@ -17,7 +17,6 @@* Moorestown platform Langwell chip. * Medfield platform Penwell chip. * Clovertrail platform Cloverview chip. -* Merrifield platform Tangier chip. */ #include <linux/module.h>
@@ -64,10 +63,6 @@ enum GPIO_REG {/* intel_mid gpio driver data */ struct intel_mid_gpio_ddata {u16 ngpio;/* number of gpio pins */ -u32 gplr_offset;/* offset of first GPLR register from base */ -u32 flis_base;/* base address of FLIS registers */ -u32 flis_len;/* length of FLIS registers */ -u32 (*get_flis_offset)(int gpio);u32 chip_irq_type;/* chip interrupt type */ };
@@ -257,15 +252,6 @@ static const struct intel_mid_gpio_ddata .chip_irq_type = INTEL_MID_IRQ_TYPE_EDGE, }; -static const struct intel_mid_gpio_ddata gpio_tangier = { - .ngpio =192 , - .gplr_offset =4 , - .flis_base =0xff0c0000 , - .flis_len =0x8000 , - .get_flis_offset =NULL , - .chip_irq_type =INTEL_MID_IRQ_TYPE_EDGE , -}; -static const struct pci_device_id intel_gpio_ids[] = { {/* Lincroft */
@@ -292,11 +278,6 @@ static const struct pci_device_id intel_ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x08f7), .driver_data = (kernel_ulong_t)&gpio_cloverview_core, }, - { -/* Tangier */ -PCI_DEVICE (PCI_VENDOR_ID_INTEL ,0x1199 ), - .driver_data = (kernel_ulong_t)&gpio_tangier, - }, { 0 } };MODULE_DEVICE_TABLE (pci, intel_gpio_ids);
Greg Kroah-Hartman
maintainerPATCH 17/138 Bluetooth: hci_intel: Fix null gpio desc pointer dereference
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Loic Poulain <[email protected]>
commit 32b9ccbc3522811c0e483637b85ae25f5491296f upstream.
gpiod_get_optional can return either ERR_PTR or NULL pointer. NULL case is not tested and then dereferenced later in desc_to_gpio. Fix this by using non optional version which returns ERR_PTR in any error case (this is not an optional gpio).
Use the same non optional version for the host-wake gpio.
--- drivers/bluetooth/hci_intel.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/bluetooth/hci_intel.c +2 -4
@@ -1234,8 +1234,7 @@ static int intel_probe(struct platform_d idev->pdev = pdev; - idev->reset =devm_gpiod_get_optional (&pdev->dev,"reset" , -GPIOD_OUT_LOW ); + idev->reset =devm_gpiod_get (&pdev->dev,"reset" ,GPIOD_OUT_LOW );if (IS_ERR (idev->reset)) {dev_err (&pdev->dev,"Unable to retrieve gpio\n" );return PTR_ERR (idev->reset);
@@ -1247,8 +1246,7 @@ static int intel_probe(struct platform_ddev_err (&pdev->dev,"No IRQ, falling back to gpio-irq\n" ); - host_wake =devm_gpiod_get_optional (&pdev->dev,"host-wake" , -GPIOD_IN ); + host_wake =devm_gpiod_get (&pdev->dev,"host-wake" ,GPIOD_IN );if (IS_ERR (host_wake)) {dev_err (&pdev->dev,"Unable to retrieve IRQ\n" ); goto no_irq;
Greg Kroah-Hartman
maintainerPATCH 18/138 pinctrl: cherryview: prevent concurrent access to GPIO controllers
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan O'Donovan <[email protected]>
commit 0bd50d719b004110e791800450ad204399100a86 upstream.
Due to a silicon issue on the Atom X5-Z8000 "Cherry Trail" processor series, a common lock must be used to prevent concurrent accesses across the 4 GPIO controllers managed by this driver.
See Intel Atom Z8000 Processor Series Specification Update (Rev. 005), errata #CHT34, for further information.
--- drivers/pinctrl/intel/pinctrl-cherryview.c | 80 +++++++++++++++-------------- 1 file changed, 44 insertions(+), 36 deletions(-)
drivers/pinctrl/intel/pinctrl-cherryview.c +44 -36
@@ -160,7 +160,6 @@ struct chv_pin_context {* @pctldev: Pointer to the pin controller device * @chip: GPIO chip in this pin controller * @regs: MMIO registers -* @lock: Lock to serialize register accesses * @intr_lines: Stores mapping between 16 HW interrupt wires and GPIO * offset (in GPIO number space) * @community: Community this pinctrl instance represents
@@ -174,7 +173,6 @@ struct chv_pinctrl {struct pinctrl_dev *pctldev;struct gpio_chip chip;void __iomem *regs; -raw_spinlock_t lock;unsigned intr_lines[16 ];const struct chv_community *community;u32 saved_intmask;
@@ -659,6 +657,17 @@ static const struct chv_community *chv_c &southeast_community, }; +/* +* Lock to serialize register accesses +* +* Due to a silicon issue, a shared lock must be used to prevent +* concurrent accesses across the 4 GPIO controllers. +* +* See Intel Atom Z8000 Processor Series Specification Update (Rev. 005), +* errata #CHT34, for further information. +*/ +static DEFINE_RAW_SPINLOCK (chv_lock); +static void __iomem *chv_padreg (struct chv_pinctrl *pctrl,unsigned offset,unsigned reg) {
@@ -720,13 +729,13 @@ static void chv_pin_dbg_show(struct pincu32 ctrl0, ctrl1;bool locked; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags); ctrl0 =readl (chv_padreg (pctrl, offset,CHV_PADCTRL0 )); ctrl1 =readl (chv_padreg (pctrl, offset,CHV_PADCTRL1 )); locked =chv_pad_locked (pctrl, offset); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);if (ctrl0 &CHV_PADCTRL0_GPIOEN ) {seq_puts (s,"GPIO " );
@@ -789,14 +798,14 @@ static int chv_pinmux_set_mux(struct pin grp = &pctrl->community->groups[group]; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags);/* Check first that the pad is not locked */ for (i =0 ; i < grp->npins; i++) {if (chv_pad_locked (pctrl, grp->pins[i])) {dev_warn (pctrl->dev,"unable to set mode for locked pin %u\n" , grp->pins[i]); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);return -EBUSY ; } }
@@ -839,7 +848,7 @@ static int chv_pinmux_set_mux(struct pin pin, altfunc->mode, altfunc->invert_oe ? "" : "not "); } -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);return 0 ; }
@@ -853,13 +862,13 @@ static int chv_gpio_request_enable(strucvoid __iomem *reg;u32 value; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags);if (chv_pad_locked (pctrl, offset)) { value =readl (chv_padreg (pctrl, offset,CHV_PADCTRL0 ));if (!(value &CHV_PADCTRL0_GPIOEN )) {/* Locked so cannot enable */ -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);return -EBUSY ; } }else {
@@ -899,7 +908,7 @@ static int chv_gpio_request_enable(strucchv_writel (value, reg); } -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);return 0 ; }
@@ -913,13 +922,13 @@ static void chv_gpio_disable_free(structvoid __iomem *reg;u32 value; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags); reg =chv_padreg (pctrl, offset,CHV_PADCTRL0 ); value =readl (reg) & ~CHV_PADCTRL0_GPIOEN ;chv_writel (value, reg); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags); } static int chv_gpio_set_direction(struct pinctrl_dev *pctldev,
@@ -931,7 +940,7 @@ static int chv_gpio_set_direction(structunsigned long flags;u32 ctrl0; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags); ctrl0 =readl (reg) & ~CHV_PADCTRL0_GPIOCFG_MASK ;if (input)
@@ -940,7 +949,7 @@ static int chv_gpio_set_direction(struct ctrl0 |=CHV_PADCTRL0_GPIOCFG_GPO <<CHV_PADCTRL0_GPIOCFG_SHIFT ;chv_writel (ctrl0, reg); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);return 0 ; }
@@ -965,10 +974,10 @@ static int chv_config_get(struct pinctrlu16 arg =0 ;u32 term; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags); ctrl0 =readl (chv_padreg (pctrl, pin,CHV_PADCTRL0 )); ctrl1 =readl (chv_padreg (pctrl, pin,CHV_PADCTRL1 )); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags); term = (ctrl0 &CHV_PADCTRL0_TERM_MASK ) >>CHV_PADCTRL0_TERM_SHIFT ;
@@ -1042,7 +1051,7 @@ static int chv_config_set_pull(struct chunsigned long flags;u32 ctrl0, pull; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags); ctrl0 =readl (reg);switch (param) {
@@ -1065,7 +1074,7 @@ static int chv_config_set_pull(struct ch pull =CHV_PADCTRL0_TERM_20K <<CHV_PADCTRL0_TERM_SHIFT ;break ;default : -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);return -EINVAL ; }
@@ -1083,7 +1092,7 @@ static int chv_config_set_pull(struct ch pull =CHV_PADCTRL0_TERM_20K <<CHV_PADCTRL0_TERM_SHIFT ;break ;default : -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);return -EINVAL ; }
@@ -1091,12 +1100,12 @@ static int chv_config_set_pull(struct chbreak ;default : -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);return -EINVAL ; }chv_writel (ctrl0, reg); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);return 0 ; }
@@ -1162,9 +1171,9 @@ static int chv_gpio_get(struct gpio_chipunsigned long flags;u32 ctrl0, cfg; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags); ctrl0 =readl (chv_padreg (pctrl, pin,CHV_PADCTRL0 )); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags); cfg = ctrl0 &CHV_PADCTRL0_GPIOCFG_MASK ; cfg >>=CHV_PADCTRL0_GPIOCFG_SHIFT ;
@@ -1182,7 +1191,7 @@ static void chv_gpio_set(struct gpio_chivoid __iomem *reg;u32 ctrl0; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags); reg =chv_padreg (pctrl, pin,CHV_PADCTRL0 ); ctrl0 =readl (reg);
@@ -1194,7 +1203,7 @@ static void chv_gpio_set(struct gpio_chichv_writel (ctrl0, reg); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags); }static int chv_gpio_get_direction (struct gpio_chip *chip,unsigned offset)
@@ -1204,9 +1213,9 @@ static int chv_gpio_get_direction(structu32 ctrl0, direction;unsigned long flags; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags); ctrl0 =readl (chv_padreg (pctrl, pin,CHV_PADCTRL0 )); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags); direction = ctrl0 &CHV_PADCTRL0_GPIOCFG_MASK ; direction >>=CHV_PADCTRL0_GPIOCFG_SHIFT ;
@@ -1244,14 +1253,14 @@ static void chv_gpio_irq_ack(struct irq_int pin =chv_gpio_offset_to_pin (pctrl,irqd_to_hwirq (d));u32 intr_line; -raw_spin_lock (&pctrl->lock); +raw_spin_lock (&chv_lock); intr_line =readl (chv_padreg (pctrl, pin,CHV_PADCTRL0 )); intr_line &=CHV_PADCTRL0_INTSEL_MASK ; intr_line >>=CHV_PADCTRL0_INTSEL_SHIFT ;chv_writel (BIT (intr_line), pctrl->regs +CHV_INTSTAT ); -raw_spin_unlock (&pctrl->lock); +raw_spin_unlock (&chv_lock); }static void chv_gpio_irq_mask_unmask (struct irq_data *d,bool mask)
@@ -1262,7 +1271,7 @@ static void chv_gpio_irq_mask_unmask(stru32 value, intr_line;unsigned long flags; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags); intr_line =readl (chv_padreg (pctrl, pin,CHV_PADCTRL0 )); intr_line &=CHV_PADCTRL0_INTSEL_MASK ;
@@ -1275,7 +1284,7 @@ static void chv_gpio_irq_mask_unmask(str value |=BIT (intr_line);chv_writel (value, pctrl->regs +CHV_INTMASK ); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags); }static void chv_gpio_irq_mask (struct irq_data *d)
@@ -1309,7 +1318,7 @@ static unsigned chv_gpio_irq_startup(strunsigned long flags;u32 intsel, value; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags); intsel =readl (chv_padreg (pctrl, pin,CHV_PADCTRL0 )); intsel &=CHV_PADCTRL0_INTSEL_MASK ; intsel >>=CHV_PADCTRL0_INTSEL_SHIFT ;
@@ -1324,7 +1333,7 @@ static unsigned chv_gpio_irq_startup(strirq_set_handler_locked (d, handler); pctrl->intr_lines[intsel] = offset; } -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags); }chv_gpio_irq_unmask (d);
@@ -1340,7 +1349,7 @@ static int chv_gpio_irq_type(struct irq_unsigned long flags;u32 value; -raw_spin_lock_irqsave (&pctrl->lock, flags); +raw_spin_lock_irqsave (&chv_lock, flags);/* * Pins which can be used as shared interrupt are configured in
@@ -1389,7 +1398,7 @@ static int chv_gpio_irq_type(struct irq_else if (type &IRQ_TYPE_LEVEL_MASK )irq_set_handler_locked (d, handle_level_irq); -raw_spin_unlock_irqrestore (&pctrl->lock, flags); +raw_spin_unlock_irqrestore (&chv_lock, flags);return 0 ; }
@@ -1501,7 +1510,6 @@ static int chv_pinctrl_probe(struct platif (i ==ARRAY_SIZE (chv_communities))return -ENODEV ; -raw_spin_lock_init (&pctrl->lock); pctrl->dev = &pdev->dev;#ifdef CONFIG_PM_SLEEP
Greg Kroah-Hartman
maintainerPATCH 19/138 arm64: dts: rockchip: fixes the gic400 2nd region size for rk3368
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Caesar Wang <[email protected]>
commit ad1cfdf518976447e6b0d31517bad4e3ebbce6bb upstream.
The 2nd additional region is the GIC virtual cpu interface register base and size.
As the gic400 of rk3368 says, the cpu interface register map as below
:
-0x0000 GICC_CTRL
.
.
.
-0x00fc GICC_IIDR
-0x1000 GICC_IDR
Obviously, the region size should be greater than 0x1000.
So we should make sure to include the GICC_IDR since the kernel will access it in some cases.
--- arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/rockchip/rk3368.dtsi +1 -1
@@ -517,7 +517,7 @@ #address-cells = <0>; reg = <0x0 0xffb71000 0x0 0x1000>, - <0x0 0xffb72000 0x0 0x1000>, + <0x0 0xffb72000 0x0 0x2000>, <0x0 0xffb74000 0x0 0x2000>, <0x0 0xffb76000 0x0 0x2000>; interrupts = <GIC_PPI 9
Greg Kroah-Hartman
maintainerPATCH 20/138 arm64: mm: avoid fdt_check_header() before the FDT is fully mapped
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ard Biesheuvel <[email protected]>
commit 04a848106193b134741672f7e4e444b50c70b631 upstream.
As reported by Zijun, the fdt_check_header() call in __fixmap_remap_fdt() is not safe since it is not guaranteed that the FDT header is mapped completely. Due to the minimum alignment of 8 bytes, the only fields we can assume to be mapped are 'magic' and 'totalsize'.
Since the OF layer is in charge of validating the FDT image, and we are only interested in making reasonably sure that the size field contains a meaningful value, replace the fdt_check_header() call with an explicit comparison of the magic field's value against the expected value.
--- arch/arm64/mm/mmu.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm64/mm/mmu.c +4 -4
@@ -652,9 +652,9 @@ void *__init fixmap_remap_fdt(phys_addr_/* * Check whether the physical FDT address is set and meets the minimum * alignment requirement. Since we are relying on MIN_FDT_ALIGN to be -* at least 8 bytes so that we can always access the size field of the -* FDT header after mapping the first chunk, double check here if that -* is indeed the case. +* at least 8 bytes so that we can always access the magic and size +* fields of the FDT header after mapping the first chunk, double check +* here if that is indeed the case. */ BUILD_BUG_ON (MIN_FDT_ALIGN <8 );if (!dt_phys || dt_phys %MIN_FDT_ALIGN )
@@ -682,7 +682,7 @@ void *__init fixmap_remap_fdt(phys_addr_create_mapping (round_down (dt_phys,SWAPPER_BLOCK_SIZE ), dt_virt_base,SWAPPER_BLOCK_SIZE , prot); -if (fdt_check_header (dt_virt) !=0 ) +if (fdt_magic (dt_virt) !=FDT_MAGIC )return NULL ; size =fdt_totalsize (dt_virt);
Greg Kroah-Hartman
maintainerPATCH 22/138 KVM: PPC: Book3S HV: Save/restore TM state in H_CEDE
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Mackerras <[email protected]>
commit 93d17397e4e2182fdaad503e2f9da46202c0f1c3 upstream.
It turns out that if the guest does a H_CEDE while the CPU is in a transactional state, and the H_CEDE does a nap, and the nap loses the architected state of the CPU (which is is allowed to do), then we lose the checkpointed state of the virtual CPU. In addition, the transactional-memory state recorded in the MSR gets reset back to non-transactional, and when we try to return to the guest, we take a TM bad thing type of program interrupt because we are trying to transition from non-transactional to transactional with a hrfid instruction, which is not permitted.
The result of the program interrupt occurring at that point is that the host CPU will hang in an infinite loop with interrupts disabled. Thus this is a denial of service vulnerability in the host which can be triggered by any guest (and depending on the guest kernel, it can potentially triggered by unprivileged userspace in the guest).
This vulnerability has been assigned the ID CVE-2016-5412.
To fix this, we save the TM state before napping and restore it on exit from the nap, when handling a H_CEDE in real mode. The case where H_CEDE exits to host virtual mode is already OK (as are other hcalls which exit to host virtual mode) because the exit path saves the TM state.
--- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 13 +++++++++++++ 1 file changed, 13 insertions(+)
arch/powerpc/kvm/book3s_hv_rmhandlers.S +13 -0
@@ -2037,6 +2037,13 @@ _GLOBAL(kvmppc_h_cede) /* r3 = vcpu poi /* save FP state */ bl kvmppc_save_fp +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM +BEGIN_FTR_SECTION + ld r9, HSTATE_KVM_VCPU(r13) + bl kvmppc_save_tm +END_FTR_SECTION_IFSET(CPU_FTR_TM) +#endif + /* * Set DEC to the smaller of DEC and HDEC, so that we wake * no later than the end of our timeslice (HDEC interrupts
@@ -2113,6 +2120,12 @@ kvm_end_cede: bl kvmhv_accumulate_time #endif +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM +BEGIN_FTR_SECTION + bl kvmppc_restore_tm +END_FTR_SECTION_IFSET(CPU_FTR_TM) +#endif + /* load up FP state */ bl kvmppc_load_fp
Greg Kroah-Hartman
maintainerPATCH 23/138 KVM: MTRR: fix kvm_mtrr_check_gfn_range_consistency page fault
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexis Dambricourt <[email protected]>
commit 30b072ce0356e8b141f4ca6da7220486fa3641d9 upstream.
The following #PF may occurs:
[ 1403.317041] BUG: unable to handle kernel paging request at 0000000200000068 [ 1403.317045] IP: [<ffffffffc04c20b0>] __mtrr_lookup_var_next+0x10/0xa0 [kvm]
[ 1403.317123] Call Trace: [ 1403.317134] [<ffffffffc04c2a65>] ? kvm_mtrr_check_gfn_range_consistency+0xc5/0x120 [kvm] [ 1403.317143] [<ffffffffc04ac11f>] ? tdp_page_fault+0x9f/0x2c0 [kvm] [ 1403.317152] [<ffffffffc0498128>] ? kvm_set_msr_common+0x858/0xc00 [kvm] [ 1403.317161] [<ffffffffc04b8883>] ? x86_emulate_insn+0x273/0xd30 [kvm] [ 1403.317171] [<ffffffffc04c04e4>] ? kvm_cpuid+0x34/0x190 [kvm] [ 1403.317180] [<ffffffffc04a5bb9>] ? kvm_mmu_page_fault+0x59/0xe0 [kvm] [ 1403.317183] [<ffffffffc0d729e1>] ? vmx_handle_exit+0x1d1/0x14a0 [kvm_intel] [ 1403.317185] [<ffffffffc0d75f3f>] ? atomic_switch_perf_msrs+0x6f/0xa0 [kvm_intel] [ 1403.317187] [<ffffffffc0d7621d>] ? vmx_vcpu_run+0x2ad/0x420 [kvm_intel] [ 1403.317196] [<ffffffffc04a0962>] ? kvm_arch_vcpu_ioctl_run+0x622/0x1550 [kvm] [ 1403.317204] [<ffffffffc049abb9>] ? kvm_arch_vcpu_load+0x59/0x210 [kvm] [ 1403.317206] [<ffffffff81036245>] ? __kernel_fpu_end+0x35/0x100 [ 1403.317213] [<ffffffffc0487eb6>] ? kvm_vcpu_ioctl+0x316/0x5d0 [kvm] [ 1403.317215] [<ffffffff81088225>] ? do_sigtimedwait+0xd5/0x220 [ 1403.317217] [<ffffffff811f84dd>] ? do_vfs_ioctl+0x9d/0x5c0 [ 1403.317224] [<ffffffffc04928ae>] ? kvm_on_user_return+0x3e/0x70 [kvm] [ 1403.317225] [<ffffffff811f8a74>] ? SyS_ioctl+0x74/0x80 [ 1403.317227] [<ffffffff815bf0b6>] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 [ 1403.317242] RIP [<ffffffffc04c20b0>] __mtrr_lookup_var_next+0x10/0xa0 [kvm]
At mtrr_lookup_fixed_next(), when the condition
'if (iter->index >= ARRAY_SIZE(iter->mtrr_state->fixed_ranges))' becomes true, mtrr_lookup_var_start() is called with iter->range with gargabe values from the fixed MTRR union field. Then, list_prepare_entry() do not call list_entry() initialization, keeping a garbage pointer in iter->range which is accessed in the following __mtrr_lookup_var_next() call.
--- arch/x86/kvm/mtrr.c | 1 + 1 file changed, 1 insertion(+)
arch/x86/kvm/mtrr.c +1 -0
@@ -539,6 +539,7 @@ static void mtrr_lookup_var_start(struct iter->fixed = false; iter->start_max = iter->start; + iter->range =NULL ; iter->range =list_prepare_entry (iter->range, &mtrr_state->head, node);__mtrr_lookup_var_next (iter);
Greg Kroah-Hartman
maintainerPATCH 44/138 EDAC: Correct channel count limit
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Borislav Petkov <[email protected]>
commit bba142957e04c400440d2df83c1b3b2dfc42e220 upstream.
c44696fff04f ("EDAC: Remove arbitrary limit on number of channels") lifted the arbitrary limit on memory controller channels in EDAC. However, the dynamic channel attributes dynamic_csrow_dimm_attr and dynamic_csrow_ce_count_attr remained 6.
This wasn't a problem except channels 6 and 7 weren't visible in sysfs on machines with more than 6 channels after the conversion to static attr groups with
2c1946b6d629 ("EDAC: Use static attribute groups for managing sysfs entries")
[ without that, we're exploding in edac_create_sysfs_mci_device()
because we're dereferencing out of the bounds of the dynamic_csrow_dimm_attr array. ]
Add attributes for channels 6 and 7 along with a guard for the future, should more channels be required and/or to sanity check for misconfigured machines.
We still need to check against the number of channels present on the MC first, as Thor reported.
--- drivers/edac/edac_mc_sysfs.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
drivers/edac/edac_mc_sysfs.c +19 -1
@@ -313,7 +313,6 @@ static struct device_type csrow_attr_typ* possible dynamic channel DIMM Label attribute files * */ -DEVICE_CHANNEL (ch0_dimm_label,S_IRUGO |S_IWUSR , channel_dimm_label_show, channel_dimm_label_store,0 ); DEVICE_CHANNEL(ch1_dimm_label, S_IRUGO | S_IWUSR,
@@ -326,6 +325,10 @@ DEVICE_CHANNEL(ch4_dimm_label, S_IRUGO | channel_dimm_label_show, channel_dimm_label_store, 4);DEVICE_CHANNEL (ch5_dimm_label,S_IRUGO |S_IWUSR , channel_dimm_label_show, channel_dimm_label_store,5 ); +DEVICE_CHANNEL (ch6_dimm_label,S_IRUGO |S_IWUSR , + channel_dimm_label_show, channel_dimm_label_store,6 ); +DEVICE_CHANNEL (ch7_dimm_label,S_IRUGO |S_IWUSR , + channel_dimm_label_show, channel_dimm_label_store,7 );/* Total possible dynamic DIMM Label attribute file table */ static struct attribute *dynamic_csrow_dimm_attr[] = {
@@ -335,6 +338,8 @@ static struct attribute *dynamic_csrow_d &dev_attr_legacy_ch3_dimm_label.attr.attr, &dev_attr_legacy_ch4_dimm_label.attr.attr, &dev_attr_legacy_ch5_dimm_label.attr.attr, + &dev_attr_legacy_ch6_dimm_label.attr.attr, + &dev_attr_legacy_ch7_dimm_label.attr.attr, NULL };
@@ -351,6 +356,10 @@ DEVICE_CHANNEL(ch4_ce_count, S_IRUGO, channel_ce_count_show, NULL, 4);DEVICE_CHANNEL (ch5_ce_count,S_IRUGO , channel_ce_count_show,NULL ,5 ); +DEVICE_CHANNEL (ch6_ce_count,S_IRUGO , + channel_ce_count_show,NULL ,6 ); +DEVICE_CHANNEL (ch7_ce_count,S_IRUGO , + channel_ce_count_show,NULL ,7 );/* Total possible dynamic ce_count attribute file table */ static struct attribute *dynamic_csrow_ce_count_attr[] = {
@@ -360,6 +369,8 @@ static struct attribute *dynamic_csrow_c &dev_attr_legacy_ch3_ce_count.attr.attr, &dev_attr_legacy_ch4_ce_count.attr.attr, &dev_attr_legacy_ch5_ce_count.attr.attr, + &dev_attr_legacy_ch6_ce_count.attr.attr, + &dev_attr_legacy_ch7_ce_count.attr.attr, NULL };
@@ -371,9 +382,16 @@ static umode_t csrow_dev_is_visible(struif (idx >= csrow->nr_channels)return 0 ; + +if (idx >=ARRAY_SIZE (dynamic_csrow_ce_count_attr) -1 ) { +WARN_ONCE (1 ,"idx: %d\n" , idx); +return 0 ; + } +/* Only expose populated DIMMs */ if (!csrow->channels[idx]->dimm->nr_pages)return 0 ; +return attr->mode; }
Greg Kroah-Hartman
maintainerPATCH 46/138 ovl: disallow overlayfs as upperdir
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <[email protected]>
commit 76bc8e2843b66f8205026365966b49ec6da39ae7 upstream.
This does not work and does not make sense. So instead of fixing it (probably not hard) just disallow.
--- fs/overlayfs/super.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/overlayfs/super.c +2 -1
@@ -376,7 +376,8 @@ static struct ovl_entry *ovl_alloc_entrystatic bool ovl_dentry_remote (struct dentry *dentry) {return dentry->d_flags & - (DCACHE_OP_REVALIDATE |DCACHE_OP_WEAK_REVALIDATE ); + (DCACHE_OP_REVALIDATE |DCACHE_OP_WEAK_REVALIDATE | +DCACHE_OP_REAL ); }static bool ovl_dentry_weird (struct dentry *dentry)
Greg Kroah-Hartman
maintainerPATCH 47/138 remoteproc: Fix potential race condition in rproc_add
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Gerlach <[email protected]>
commit d2e12e66a939c54ed84e5f1b6947f0c45f6c56eb upstream.
rproc_add adds the newly created remoteproc to a list for use by rproc_get_by_phandle and then does some additional processing to finish adding the remoteproc. This leaves a small window of time in which the rproc is available in the list but not yet fully initialized, so if another driver comes along and gets a handle to the rproc, it will be invalid. Rearrange the code in rproc_add to make sure the rproc is added to the list only after it has been successfuly initialized.
--- drivers/remoteproc/remoteproc_core.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
drivers/remoteproc/remoteproc_core.c +9 -6
@@ -1239,11 +1239,6 @@ int rproc_add(struct rproc *rproc)if (ret <0 )return ret; -/* expose to rproc_get_by_phandle users */ -mutex_lock (&rproc_list_mutex); -list_add (&rproc->node, &rproc_list); -mutex_unlock (&rproc_list_mutex); -dev_info (dev,"%s is available\n" , rproc->name);dev_info (dev,"Note: remoteproc is still under development and considered experimental.\n" );
@@ -1251,8 +1246,16 @@ int rproc_add(struct rproc *rproc)/* create debugfs entries */ rproc_create_debug_dir (rproc); + ret =rproc_add_virtio_devices (rproc); +if (ret <0 ) +return ret; + +/* expose to rproc_get_by_phandle users */ +mutex_lock (&rproc_list_mutex); +list_add (&rproc->node, &rproc_list); +mutex_unlock (&rproc_list_mutex); -return rproc_add_virtio_devices (rproc); +return 0 ; }EXPORT_SYMBOL (rproc_add);
Greg Kroah-Hartman
maintainerPATCH 48/138 ARC: mm: dont loose PTE_SPECIAL in pte_modify()
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vineet Gupta <[email protected]>
commit 3925a16ae980c79d1a8fd182d7f9487da1edd4dc upstream.
LTP madvise05 was generating mm splat
| [ARCLinux]# /sd/ltp/testcases/bin/madvise05 | BUG: Bad page map in process madvise05 pte:80e08211 pmd:9f7d4000 | page:9fdcfc90 count:1 mapcount:-1 mapping: (null) index:0x0 flags: 0x404(referenced|reserved) | page dumped because: bad pte | addr:200b8000 vm_flags:00000070 anon_vma: (null) mapping: (null) index:1005c | file: (null) fault: (null) mmap: (null) readpage: (null) | CPU: 2 PID: 6707 Comm: madvise05
And for newer kernels, the system was rendered unusable afterwards.
The problem was mprotect->pte_modify() clearing PTE_SPECIAL (which is set to identify the special zero page wired to the pte). When pte was finally unmapped, special casing for zero page was not done, and instead it was treated as a "normal" page, tripping on the map counts etc.
This fixes ARC STAR 9001053308
--- arch/arc/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arc/include/asm/pgtable.h +1 -1
@@ -110,7 +110,7 @@#define ___DEF (_PAGE_PRESENT | _PAGE_CACHEABLE)/* Set of bits not changed in pte_modify */ -#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY) +#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_SPECIAL)/* More Abbrevaited helpers */ #define PAGE_U_NONE __pgprot(___DEF)
Greg Kroah-Hartman
maintainerPATCH 49/138 jbd2: make journal y2038 safe
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit abcfb5d979892fc8b12574551fc907c05fe1b11b upstream.
The jbd2 journal stores the commit time in 64-bit seconds and 32-bit nanoseconds, which avoids an overflow in 2038, but it gets the numbers from current_kernel_time(), which uses 'long' seconds on 32-bit architectures.
This simply changes the code to call current_kernel_time64() so we use 64-bit seconds consistently.
--- fs/jbd2/commit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/jbd2/commit.c +1 -1
@@ -124,7 +124,7 @@ static int journal_submit_commit_record(struct commit_header *tmp;struct buffer_head *bh;int ret; -struct timespec now =current_kernel_time (); +struct timespec64 now =current_kernel_time64 (); *cbh =NULL ;
Greg Kroah-Hartman
maintainerPATCH 64/138 nfsd: dont return an unhashed lock stateid after taking mutex
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <[email protected]>
commit dd257933fa4b9fea66a1195f8a15111029810abc upstream.
nfsd4_lock will take the st_mutex before working with the stateid it gets, but between the time when we drop the cl_lock and take the mutex, the stateid could become unhashed (a'la FREE_STATEID). If that happens the lock stateid returned to the client will be forgotten.
Fix this by first moving the st_mutex acquisition into lookup_or_create_lock_state. Then, have it check to see if the lock stateid is still hashed after taking the mutex. If it's not, then put the stateid and try the find/create again.
--- fs/nfsd/nfs4state.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-)
fs/nfsd/nfs4state.c +20 -5
@@ -5502,7 +5502,7 @@ static __be32 lookup_or_create_lock_state(struct nfsd4_compound_state *cstate, struct nfs4_ol_stateid *ost, struct nfsd4_lock *lock, - struct nfs4_ol_stateid **lst, bool *new) + struct nfs4_ol_stateid **plst, bool *new) { __be32 status;struct nfs4_file *fi = ost->st_stid.sc_file;
@@ -5510,7 +5510,9 @@ lookup_or_create_lock_state(struct nfsd4struct nfs4_client *cl = oo->oo_owner.so_client;struct inode *inode =d_inode (cstate->current_fh.fh_dentry);struct nfs4_lockowner *lo; +struct nfs4_ol_stateid *lst;unsigned int strhashval; +bool hashed; lo =find_lockowner_str (cl, &lock->lk_new_owner);if (!lo) {
@@ -5526,12 +5528,27 @@ lookup_or_create_lock_state(struct nfsd4 goto out; } - *lst =find_or_create_lock_stateid (lo, fi, inode, ost, new); -if (*lst ==NULL ) { +retry: + lst =find_or_create_lock_stateid (lo, fi, inode, ost, new); +if (lst ==NULL ) { status = nfserr_jukebox; goto out; } + +mutex_lock (&lst->st_mutex); + +/* See if it's still hashed to avoid race with FREE_STATEID */ +spin_lock (&cl->cl_lock); + hashed = !list_empty (&lst->st_perfile); +spin_unlock (&cl->cl_lock); + +if (!hashed) { +mutex_unlock (&lst->st_mutex); +nfs4_put_stid (&lst->st_stid); + goto retry; + } status = nfs_ok; + *plst = lst; out:nfs4_put_stateowner (&lo->lo_owner);return status;
@@ -5598,8 +5615,6 @@ nfsd4_lock(struct svc_rqst *rqstp, struc goto out; status =lookup_or_create_lock_state (cstate, open_stp, lock, &lock_stp, &new); -if (status == nfs_ok) -mutex_lock (&lock_stp->st_mutex); }else { status = nfs4_preprocess_seqid_op(cstate, lock->lk_old_lock_seqid,
Greg Kroah-Hartman
maintainerPATCH 66/138 iommu/exynos: Suppress unbinding to prevent system failure
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <[email protected]>
commit b54b874fbaf5e024723e50dfb035a9916d6752b4 upstream.
Removal of IOMMU driver cannot be done reliably, so Exynos IOMMU driver doesn't support this operation. It is essential for system operation, so it makes sense to prevent unbinding by disabling bind/unbind sysfs feature for SYSMMU controller driver to avoid kernel ops or trashing memory caused by such operation.
--- drivers/iommu/exynos-iommu.c | 1 + 1 file changed, 1 insertion(+)
drivers/iommu/exynos-iommu.c +1 -0
@@ -647,6 +647,7 @@ static struct platform_driver exynos_sys .name = "exynos-sysmmu", .of_match_table = sysmmu_of_match, .pm = &sysmmu_pm_ops, + .suppress_bind_attrs = true, } };
Greg Kroah-Hartman
maintainerPATCH 67/138 iommu/vt-d: Return error code in domain_context_mapping_one()
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Yang <[email protected]>
commit 5c365d18a73d3979db37006eaacefc0008869c0f upstream.
In 'commit <55d940430ab9> ("iommu/vt-d: Get rid of domain->iommu_lock")', the error handling path is changed a little, which makes the function always return 0.
This path fixes this.
--- drivers/iommu/intel-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iommu/intel-iommu.c +1 -1
@@ -2032,7 +2032,7 @@ out_unlock:spin_unlock (&iommu->lock);spin_unlock_irqrestore (&device_domain_lock, flags); -return 0 ; +return ret; }struct domain_context_mapping_data {
Greg Kroah-Hartman
maintainerPATCH 68/138 iommu/amd: Handle IOMMU_DOMAIN_DMA in ops->domain_free call-back
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joerg Roedel <[email protected]>
commit cda7005ba2cbd0744fea343dd5b2aa637eba5b9e upstream.
This domain type is not yet handled in theiommu_ops->domain_free() call-back. Fix that.
--- drivers/iommu/amd_iommu.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-)
drivers/iommu/amd_iommu.c +18 -9
@@ -2970,9 +2970,7 @@ static struct iommu_domain *amd_iommu_dostatic void amd_iommu_domain_free (struct iommu_domain *dom) {struct protection_domain *domain; - -if (!dom) -return ; +struct dma_ops_domain *dma_dom; domain =to_pdomain (dom);
@@ -2981,13 +2979,24 @@ static void amd_iommu_domain_free(structBUG_ON (domain->dev_cnt !=0 ); -if (domain->mode !=PAGE_MODE_NONE ) -free_pagetable (domain); - -if (domain->flags &PD_IOMMUV2_MASK ) -free_gcr3_table (domain); +if (!dom) +return ; -protection_domain_free (domain); +switch (dom->type) { +case IOMMU_DOMAIN_DMA : + dma_dom = domain->priv; +dma_ops_domain_free (dma_dom); +break ; +default : +if (domain->mode !=PAGE_MODE_NONE ) +free_pagetable (domain); + +if (domain->flags &PD_IOMMUV2_MASK ) +free_gcr3_table (domain); + +protection_domain_free (domain); +break ; + } } static void amd_iommu_detach_device(struct iommu_domain *dom,
Greg Kroah-Hartman
maintainerPATCH 69/138 iommu/amd: Init unity mappings only for dma_ops domains
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joerg Roedel <[email protected]>
commit b548e786ce47017107765bbeb0f100202525ea83 upstream.
The default domain for a device might also be identity-mapped. In this case the kernel would crash when unity mappings are defined for the device. Fix that by making sure the domain is a dma_ops domain.
--- drivers/iommu/amd_iommu.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/iommu/amd_iommu.c +4 -2
@@ -352,9 +352,11 @@ static void init_iommu_group(struct deviif (!domain) goto out; - dma_domain =to_pdomain (domain)->priv; +if (to_pdomain (domain)->flags ==PD_DMA_OPS_MASK ) { + dma_domain =to_pdomain (domain)->priv; +init_unity_mappings_for_device (dev, dma_domain); + } -init_unity_mappings_for_device (dev, dma_domain); out:iommu_group_put (group); }
Greg Kroah-Hartman
maintainerPATCH 70/138 iommu/amd: Update Alias-DTE in update_device_table()
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joerg Roedel <[email protected]>
commit 3254de6bf74fe94c197c9f819fe62a3a3c36f073 upstream.
Not doing so might cause IO-Page-Faults when a device uses an alias request-id and the alias-dte is left in a lower page-mode which does not cover the address allocated from the iova-allocator.
--- drivers/iommu/amd_iommu.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/iommu/amd_iommu.c +8 -1
@@ -2324,8 +2324,15 @@ static void update_device_table(struct p {struct iommu_dev_data *dev_data; -list_for_each_entry (dev_data, &domain->dev_list, list) +list_for_each_entry (dev_data, &domain->dev_list, list) {set_dte_entry (dev_data->devid, domain, dev_data->ats.enabled); + +if (dev_data->devid == dev_data->alias) +continue ; + +/* There is an alias, update device table entry for it */ +set_dte_entry (dev_data->alias, domain, dev_data->ats.enabled); + } }static void update_domain (struct protection_domain *domain)
Greg Kroah-Hartman
maintainerPATCH 71/138 audit: fix a double fetch in audit_log_single_execve_arg()
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Moore <[email protected]>
commit 43761473c254b45883a64441dd0bc85a42f3645c upstream.
There is a double fetch problem in audit_log_single_execve_arg() where we first check the execve(2) argumnets for any "bad" characters which would require hex encoding and then re-fetch the arguments for logging in the audit record[1]. Of course this leaves a window of opportunity for an unsavory application to munge with the data.
This patch reworks things by only fetching the argument data once[2] into a buffer where it is scanned and logged into the audit records(s). In addition to fixing the double fetch, this patch improves on the original code in a few other ways: better handling of large arguments which require encoding, stricter record length checking, and some performance improvements (completely unverified, but we got rid of some strlen() calls, that's got to be a good thing).
As part of the development of this patch, I've also created a basic regression test for the audit-testsuite, the test can be tracked on GitHub at the following link:
* https://github.com/linux-audit/audit-testsuite/issues/25
[1] If you pay careful attention, there is actually a triple fetch problem due to a strnlen_user() call at the top of the function.
[2] This is a tiny white lie, we do make a call to strnlen_user() prior to fetching the argument data. I don't like it, but due to the way the audit record is structured we really have no choice unless we copy the entire argument at once (which would require a rather wasteful allocation). The good news is that with this patch the kernel no longer relies on this strnlen_user() value for anything beyond recording it in the log, we also update it with a trustworthy value whenever possible.
--- kernel/auditsc.c | 332 +++++++++++++++++++++++++++---------------------------- 1 file changed, 164 insertions(+), 168 deletions(-)
kernel/auditsc.c +164 -168
@@ -73,6 +73,7 @@#include <linux/compat.h> #include <linux/ctype.h> #include <linux/string.h> +#include <linux/uaccess.h> #include <uapi/linux/limits.h> #include "audit.h"
@@ -82,7 +83,8 @@#define AUDITSC_SUCCESS 1#define AUDITSC_FAILURE 2 -/* no execve audit message should be longer than this (userspace limits) */ +/* no execve audit message should be longer than this (userspace limits), +* see the note near the top of audit_log_execve_info() about this value */ #define MAX_EXECVE_AUDIT_LEN 7500/* max length to print of cmdline/proctitle value during audit */
@@ -988,184 +990,178 @@ static int audit_log_pid_context(structreturn rc; } -/* -* to_send and len_sent accounting are very loose estimates. We aren't -* really worried about a hard cap to MAX_EXECVE_AUDIT_LEN so much as being -* within about 500 bytes (next page boundary) -* -* why snprintf? an int is up to 12 digits long. if we just assumed when -* logging that a[%d]= was going to be 16 characters long we would be wasting -* space in every audit message. In one 7500 byte message we can log up to -* about 1000 min size arguments. That comes down to about 50% waste of space -* if we didn't do the snprintf to find out how long arg_num_len was. -*/ -static int audit_log_single_execve_arg (struct audit_context *context, -struct audit_buffer **ab, -int arg_num, -size_t *len_sent, -const char __user *p, -char *buf) -{ -char arg_num_len_buf[12 ]; -const char __user *tmp_p = p; -/* how many digits are in arg_num? 5 is the length of ' a=""' */ -size_t arg_num_len =snprintf (arg_num_len_buf,12 ,"%d" , arg_num) +5 ; -size_t len, len_left, to_send; -size_t max_execve_audit_len =MAX_EXECVE_AUDIT_LEN ; -unsigned int i, has_cntl =0 , too_long =0 ; -int ret; - -/* strnlen_user includes the null we don't want to send */ - len_left = len =strnlen_user (p,MAX_ARG_STRLEN ) -1 ; +static void audit_log_execve_info (struct audit_context *context, +struct audit_buffer **ab) +{ +long len_max; +long len_rem; +long len_full; +long len_buf; +long len_abuf; +long len_tmp; +bool require_data; +bool encode; +unsigned int iter; +unsigned int arg; +char *buf_head; +char *buf; +const char __user *p = (const char __user *)current->mm->arg_start; -/* -* We just created this mm, if we can't find the strings -* we just copied into it something is _very_ wrong. Similar -* for strings that are too long, we should not have created -* any. -*/ -if (WARN_ON_ONCE (len <0 || len >MAX_ARG_STRLEN -1 )) { -send_sig (SIGKILL , current,0 ); -return -1 ; +/* NOTE: this buffer needs to be large enough to hold all the non-arg +* data we put in the audit record for this argument (see the +* code below) ... at this point in time 96 is plenty */ +char abuf[96 ]; + +/* NOTE: we set MAX_EXECVE_AUDIT_LEN to a rather arbitrary limit, the +* current value of 7500 is not as important as the fact that it +* is less than 8k, a setting of 7500 gives us plenty of wiggle +* room if we go over a little bit in the logging below */ +WARN_ON_ONCE (MAX_EXECVE_AUDIT_LEN >7500 ); + len_max =MAX_EXECVE_AUDIT_LEN ; + +/* scratch buffer to hold the userspace args */ + buf_head =kmalloc (MAX_EXECVE_AUDIT_LEN +1 ,GFP_KERNEL ); +if (!buf_head) { +audit_panic ("out of memory for argv string" ); +return ; } + buf = buf_head; + +audit_log_format (*ab,"argc=%d" , context->execve.argc); -/* walk the whole argument looking for non-ascii chars */ + len_rem = len_max; + len_buf =0 ; + len_full =0 ; + require_data = true; + encode = false; + iter =0 ; + arg =0 ;do { -if (len_left >MAX_EXECVE_AUDIT_LEN ) - to_send =MAX_EXECVE_AUDIT_LEN ; -else - to_send = len_left; - ret =copy_from_user (buf, tmp_p, to_send); -/* -* There is no reason for this copy to be short. We just -* copied them here, and the mm hasn't been exposed to user- -* space yet. -*/ -if (ret) { -WARN_ON (1 ); -send_sig (SIGKILL , current,0 ); -return -1 ; - } - buf[to_send] ='\0' ; - has_cntl =audit_string_contains_control (buf, to_send); -if (has_cntl) { -/* -* hex messages get logged as 2 bytes, so we can only -* send half as much in each message -*/ - max_execve_audit_len =MAX_EXECVE_AUDIT_LEN /2 ; -break ; - } - len_left -= to_send; - tmp_p += to_send; - }while (len_left >0 ); - - len_left = len; - -if (len > max_execve_audit_len) - too_long =1 ; - -/* rewalk the argument actually logging the message */ -for (i =0 ; len_left >0 ; i++) { -int room_left; - -if (len_left > max_execve_audit_len) - to_send = max_execve_audit_len; -else - to_send = len_left; - -/* do we have space left to send this argument in this ab? */ - room_left =MAX_EXECVE_AUDIT_LEN - arg_num_len - *len_sent; -if (has_cntl) - room_left -= (to_send *2 ); -else - room_left -= to_send; -if (room_left <0 ) { - *len_sent =0 ; -audit_log_end (*ab); - *ab =audit_log_start (context,GFP_KERNEL ,AUDIT_EXECVE ); -if (!*ab) -return 0 ; - } +/* NOTE: we don't ever want to trust this value for anything +* serious, but the audit record format insists we +* provide an argument length for really long arguments, +* e.g. > MAX_EXECVE_AUDIT_LEN, so we have no choice but +* to use strncpy_from_user() to obtain this value for +* recording in the log, although we don't use it +* anywhere here to avoid a double-fetch problem */ +if (len_full ==0 ) + len_full =strnlen_user (p,MAX_ARG_STRLEN ) -1 ; + +/* read more data from userspace */ +if (require_data) { +/* can we make more room in the buffer? */ +if (buf != buf_head) { +memmove (buf_head, buf, len_buf); + buf = buf_head; + } -/* -* first record needs to say how long the original string was -* so we can be sure nothing was lost. -*/ -if ((i ==0 ) && (too_long)) -audit_log_format (*ab," a%d_len=%zu" , arg_num, - has_cntl ?2 *len : len); - -/* -* normally arguments are small enough to fit and we already -* filled buf above when we checked for control characters -* so don't bother with another copy_from_user -*/ -if (len >= max_execve_audit_len) - ret =copy_from_user (buf, p, to_send); -else - ret =0 ; -if (ret) { -WARN_ON (1 ); -send_sig (SIGKILL , current,0 ); -return -1 ; - } - buf[to_send] ='\0' ; +/* fetch as much as we can of the argument */ + len_tmp =strncpy_from_user (&buf_head[len_buf], p, + len_max - len_buf); +if (len_tmp == -EFAULT ) { +/* unable to copy from userspace */ +send_sig (SIGKILL , current,0 ); + goto out; + }else if (len_tmp == (len_max - len_buf)) { +/* buffer is not large enough */ + require_data = true; +/* NOTE: if we are going to span multiple +* buffers force the encoding so we stand +* a chance at a sane len_full value and +* consistent record encoding */ + encode = true; + len_full = len_full *2 ; + p += len_tmp; + }else { + require_data = false; +if (!encode) + encode =audit_string_contains_control ( + buf, len_tmp); +/* try to use a trusted value for len_full */ +if (len_full < len_max) + len_full = (encode ? + len_tmp *2 : len_tmp); + p += len_tmp +1 ; + } + len_buf += len_tmp; + buf_head[len_buf] ='\0' ; -/* actually log it */ -audit_log_format (*ab," a%d" , arg_num); -if (too_long) -audit_log_format (*ab,"[%d]" , i); -audit_log_format (*ab,"=" ); -if (has_cntl) -audit_log_n_hex (*ab, buf, to_send); -else -audit_log_string (*ab, buf); - - p += to_send; - len_left -= to_send; - *len_sent += arg_num_len; -if (has_cntl) - *len_sent += to_send *2 ; -else - *len_sent += to_send; - } -/* include the null we didn't log */ -return len +1 ; -} +/* length of the buffer in the audit record? */ + len_abuf = (encode ? len_buf *2 : len_buf +2 ); + } -static void audit_log_execve_info (struct audit_context *context, -struct audit_buffer **ab) -{ -int i, len; -size_t len_sent =0 ; -const char __user *p; -char *buf; +/* write as much as we can to the audit log */ +if (len_buf >0 ) { +/* NOTE: some magic numbers here - basically if we +* can't fit a reasonable amount of data into the +* existing audit buffer, flush it and start with +* a new buffer */ +if ((sizeof (abuf) +8 ) > len_rem) { + len_rem = len_max; +audit_log_end (*ab); + *ab =audit_log_start (context, +GFP_KERNEL ,AUDIT_EXECVE ); +if (!*ab) + goto out; + } - p = (const char __user *)current->mm->arg_start; +/* create the non-arg portion of the arg record */ + len_tmp =0 ; +if (require_data || (iter >0 ) || + ((len_abuf +sizeof (abuf)) > len_rem)) { +if (iter ==0 ) { + len_tmp +=snprintf (&abuf[len_tmp], +sizeof (abuf) - len_tmp, +" a%d_len=%lu" , + arg, len_full); + } + len_tmp +=snprintf (&abuf[len_tmp], +sizeof (abuf) - len_tmp, +" a%d[%d]=" , arg, iter++); + }else + len_tmp +=snprintf (&abuf[len_tmp], +sizeof (abuf) - len_tmp, +" a%d=" , arg); +WARN_ON (len_tmp >=sizeof (abuf)); + abuf[sizeof (abuf) -1 ] ='\0' ; + +/* log the arg in the audit record */ +audit_log_format (*ab,"%s" , abuf); + len_rem -= len_tmp; + len_tmp = len_buf; +if (encode) { +if (len_abuf > len_rem) + len_tmp = len_rem /2 ;/* encoding */ +audit_log_n_hex (*ab, buf, len_tmp); + len_rem -= len_tmp *2 ; + len_abuf -= len_tmp *2 ; + }else { +if (len_abuf > len_rem) + len_tmp = len_rem -2 ;/* quotes */ +audit_log_n_string (*ab, buf, len_tmp); + len_rem -= len_tmp +2 ; +/* don't subtract the "2" because we still need +* to add quotes to the remaining string */ + len_abuf -= len_tmp; + } + len_buf -= len_tmp; + buf += len_tmp; + } -audit_log_format (*ab,"argc=%d" , context->execve.argc); +/* ready to move to the next argument? */ +if ((len_buf ==0 ) && !require_data) { + arg++; + iter =0 ; + len_full =0 ; + require_data = true; + encode = false; + } + }while (arg < context->execve.argc); -/* -* we need some kernel buffer to hold the userspace args. Just -* allocate one big one rather than allocating one of the right size -* for every single argument inside audit_log_single_execve_arg() -* should be <8k allocation so should be pretty safe. -*/ - buf =kmalloc (MAX_EXECVE_AUDIT_LEN +1 ,GFP_KERNEL ); -if (!buf) { -audit_panic ("out of memory for argv string" ); -return ; - } +/* NOTE: the caller handles the final audit_log_end() call */ -for (i =0 ; i < context->execve.argc; i++) { - len =audit_log_single_execve_arg (context, ab, i, - &len_sent, p, buf); -if (len <=0 ) -break ; - p += len; - } -kfree (buf); +out: +kfree (buf_head); }static void show_special (struct audit_context *context,int *call_panic)
Greg Kroah-Hartman
maintainerPATCH 72/138 ARM: dts: sunxi: Add a startup delay for fixed regulator enabled phys
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit fc51b632c7b047c25807023b76f3877aed19c770 upstream.
It seems that recent kernels have a shorter timeout when scanning for ethernet phys causing us to hit a timeout on boards where the phy's regulator gets enabled just before scanning, which leads to non working ethernet.
A 10ms startup delay seems to be enough to fix it, this commit adds a 20ms startup delay just to be safe.
This has been tested on a sun4i-a10-a1000 and sun5i-a10s-wobo-i5 board, both of which have non-working ethernet on recent kernels without this fix.
--- arch/arm/boot/dts/sun4i-a10-a1000.dts | 1 + arch/arm/boot/dts/sun4i-a10-hackberry.dts | 1 + arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts | 1 + arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts | 1 + 4 files changed, 4 insertions(+)
arch/arm/boot/dts/sun4i-a10-a1000.dts +1 -0
@@ -84,6 +84,7 @@ regulator-name = "emac-3v3"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; + startup-delay-us = <20000>; enable-active-high; gpio = <&pio 7 15 GPIO_ACTIVE_HIGH>; };
arch/arm/boot/dts/sun4i-a10-hackberry.dts +1 -0
@@ -66,6 +66,7 @@ regulator-name = "emac-3v3"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; + startup-delay-us = <20000>; enable-active-high; gpio = <&pio 7 19 GPIO_ACTIVE_HIGH>; };
arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts +1 -0
@@ -80,6 +80,7 @@ regulator-name = "emac-3v3"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; + startup-delay-us = <20000>; enable-active-high; gpio = <&pio 7 19 GPIO_ACTIVE_HIGH>; /* PH19 */ };
arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts +1 -0
@@ -79,6 +79,7 @@ regulator-name = "emac-3v3"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; + startup-delay-us = <20000>; enable-active-high; gpio = <&pio 0 2 GPIO_ACTIVE_HIGH>; };
Greg Kroah-Hartman
maintainerPATCH 74/138 w1:omap_hdq: fix regression
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: H. Nikolaus Schaller <[email protected]>
commit ecfaf0c42fc4306b5ec4bf6be01b66f8fe9a9733 upstream.
Commit e93762bbf681 ("w1: masters: omap_hdq: add support for 1-wire mode") added a statement to clear the hdq_irqstatus flags in hdq_read_byte().
If the hdq reading process is scheduled slowly or interrupts are disabled for a while the hardware read activity might already be finished on entry of hdq_read_byte(). And hdq_isr() already has set the hdq_irqstatus to 0x6 (can be seen in debug mode) denoting that both, the TXCOMPLETE and RXCOMPLETE interrupts occurred in parallel.
This means there is no need to wait and the hdq_read_byte() can just read the byte from the hdq controller.
By resetting hdq_irqstatus to 0 the read process is forced to be always waiting again (because the if statement always succeeds) but the hardware will not issue another RXCOMPLETE interrupt. This results in a false timeout.
After such a situation the hdq bus hangs.
--- drivers/w1/masters/omap_hdq.c | 2 -- 1 file changed, 2 deletions(-)
drivers/w1/masters/omap_hdq.c +0 -2
@@ -390,8 +390,6 @@ static int hdq_read_byte(struct hdq_data goto out; } - hdq_data->hdq_irqstatus =0 ; -if (!(hdq_data->hdq_irqstatus &OMAP_HDQ_INT_STATUS_RXCOMPLETE )) { hdq_reg_merge(hdq_data, OMAP_HDQ_CTRL_STATUS, OMAP_HDQ_CTRL_STATUS_DIR | OMAP_HDQ_CTRL_STATUS_GO,
Greg Kroah-Hartman
maintainerPATCH 76/138 drm/amdgpu: Poll for both connect/disconnect on analog connectors
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude <[email protected]>
commit b636a1b3d624b49b23cc1be2f9f6bcbb89aca855 upstream.
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not disconnections. Because of this, we end up losing hotplug polling for analog connectors once they get connected.
Easy way to reproduce:
- Grab a machine with an AMD GPU and a VGA port
- Plug a monitor into the VGA port, wait for it to update the connector from disconnected to connected
- Disconnect the monitor on VGA, a hotplug event is never sent for the removal of the connector.
Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good idea since doing VGA polling can sometimes result in having to mess with the DAC voltages to figure out whether or not there's actually something there since VGA doesn't have HPD. Doing this would have the potential of showing visible artifacts on the screen every time we ran a poll while a VGA display was connected. Luckily, amdgpu_vga_detect() only resorts to this sort of polling if the poll is forced, and DRM's polling helper doesn't force it's polls.
Additionally, this removes some assignments to connector->polled that weren't actually doing anything.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +4 -3
@@ -1690,7 +1690,6 @@ amdgpu_connector_add(struct amdgpu_devic DRM_MODE_SCALE_NONE);/* no HPD on analog connectors */ amdgpu_connector->hpd.hpd =AMDGPU_HPD_NONE ; - connector->polled =DRM_CONNECTOR_POLL_CONNECT ; connector->interlace_allowed = true; connector->doublescan_allowed = true;break ;
@@ -1893,8 +1892,10 @@ amdgpu_connector_add(struct amdgpu_devic }if (amdgpu_connector->hpd.hpd ==AMDGPU_HPD_NONE ) { -if (i2c_bus->valid) - connector->polled =DRM_CONNECTOR_POLL_CONNECT ; +if (i2c_bus->valid) { + connector->polled =DRM_CONNECTOR_POLL_CONNECT | +DRM_CONNECTOR_POLL_DISCONNECT ; + } }else connector->polled =DRM_CONNECTOR_POLL_HPD ;
Greg Kroah-Hartman
maintainerPATCH 77/138 drm/amdgpu: support backlight control for UNIPHY3
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit dba6c4fa26ccf47661be5b68dba87e746fa137d8 upstream.
Same interface as other UNIPHY blocks
--- drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c +1 -0
@@ -98,6 +98,7 @@ amdgpu_atombios_encoder_set_backlight_lecase ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA :case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1 :case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2 : +case ENCODER_OBJECT_ID_INTERNAL_UNIPHY3 :if (dig->backlight_level ==0 )amdgpu_atombios_encoder_setup_dig_transmitter (encoder,ATOM_TRANSMITTER_ACTION_LCD_BLOFF ,0 ,0 );
Greg Kroah-Hartman
maintainerPATCH 78/138 drm/amdgpu: Disable RPM helpers while reprobing connectors on resume
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude <[email protected]>
commit 23a1a9e54e71593fe5657e883662995d181d2d6b upstream.
Just about all of amdgpu's connector probing functions try to acquire runtime PM refs. If we try to do this in the context of amdgpu_resume_kms by calling drm_helper_hpd_irq_event(), we end up deadlocking the system.
Since we're guaranteed to be holding the spinlock for RPM in amdgpu_resume_kms, and we already know the GPU is in working order, we need to prevent the RPM helpers from trying to run during the initial connector reprobe on resume.
There's a couple of solutions I've explored for fixing this, but this one by far seems to be the simplest and most reliable (plus I'm pretty sure that's what disable_depth is there for anyway).
Reproduction recipe:
- Get any laptop dual GPUs using PRIME
- Make sure runtime PM is enabled for amdgpu
- Boot the machine
- If the machine managed to boot without hanging, switch out of X to another VT. This should definitely cause X to hang infinitely.
Changes since v1:
- add appropriate #ifdef checks for CONFIG_PM. This is not very useful, but it appears some kernel test suites test compiling amdgpu with CONFIG_PM disabled, which results in this patch breaking the builds if we don't include this #ifdef
--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +16 -0
@@ -1793,7 +1793,23 @@ int amdgpu_resume_kms(struct drm_device }drm_kms_helper_poll_enable (dev); + +/* +* Most of the connector probing functions try to acquire runtime pm +* refs to ensure that the GPU is powered on when connector polling is +* performed. Since we're calling this from a runtime PM callback, +* trying to acquire rpm refs will cause us to deadlock. +* +* Since we're guaranteed to be holding the rpm lock, it's safe to +* temporarily disable the rpm helpers so this doesn't deadlock us. +*/ +#ifdef CONFIG_PM + dev->dev->power.disable_depth++; +#endif drm_helper_hpd_irq_event (dev); +#ifdef CONFIG_PM + dev->dev->power.disable_depth--; +#endif if (fbcon) {amdgpu_fbdev_set_suspend (adev,0 );
Greg Kroah-Hartman
maintainerPATCH 80/138 drm/amdgpu/gmc7: add missing mullins case
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 7f555c8e5a84b348c2b76f4ca78eae7222354c03 upstream.
Looks like this got missed when we ported the code from radeon.
--- drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c +1 -0
@@ -167,6 +167,7 @@ static int gmc_v7_0_init_microcode(strucbreak ;case CHIP_KAVERI :case CHIP_KABINI : +case CHIP_MULLINS :return 0 ;default :BUG (); }
Greg Kroah-Hartman
maintainerPATCH 82/138 drm/radeon: Poll for both connect/disconnect on analog connectors
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude <[email protected]>
commit 14ff8d48f2235295dfb3117693008e367b49cdb5 upstream.
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not disconnections. Because of this, we end up losing hotplug polling for analog connectors once they get connected.
Easy way to reproduce:
- Grab a machine with a radeon GPU and a VGA port
- Plug a monitor into the VGA port, wait for it to update the connector from disconnected to connected
- Disconnect the monitor on VGA, a hotplug event is never sent for the removal of the connector.
Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good idea since doing VGA polling can sometimes result in having to mess with the DAC voltages to figure out whether or not there's actually something there since VGA doesn't have HPD. Doing this would have the potential of showing visible artifacts on the screen every time we ran a poll while a VGA display was connected. Luckily, radeon_vga_detect() only resorts to this sort of polling if the poll is forced, and DRM's polling helper doesn't force it's polls.
Additionally, this removes some assignments to connector->polled that weren't actually doing anything.
--- drivers/gpu/drm/radeon/radeon_connectors.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
drivers/gpu/drm/radeon/radeon_connectors.c +9 -6
@@ -2058,7 +2058,6 @@ radeon_add_atom_connector(struct drm_dev RADEON_OUTPUT_CSC_BYPASS);/* no HPD on analog connectors */ radeon_connector->hpd.hpd =RADEON_HPD_NONE ; - connector->polled =DRM_CONNECTOR_POLL_CONNECT ; connector->interlace_allowed = true; connector->doublescan_allowed = true;break ;
@@ -2308,8 +2307,10 @@ radeon_add_atom_connector(struct drm_dev }if (radeon_connector->hpd.hpd ==RADEON_HPD_NONE ) { -if (i2c_bus->valid) - connector->polled =DRM_CONNECTOR_POLL_CONNECT ; +if (i2c_bus->valid) { + connector->polled =DRM_CONNECTOR_POLL_CONNECT | +DRM_CONNECTOR_POLL_DISCONNECT ; + } }else connector->polled =DRM_CONNECTOR_POLL_HPD ;
@@ -2385,7 +2386,6 @@ radeon_add_legacy_connector(struct drm_d 1);/* no HPD on analog connectors */ radeon_connector->hpd.hpd =RADEON_HPD_NONE ; - connector->polled =DRM_CONNECTOR_POLL_CONNECT ; connector->interlace_allowed = true; connector->doublescan_allowed = true;break ;
@@ -2470,10 +2470,13 @@ radeon_add_legacy_connector(struct drm_d }if (radeon_connector->hpd.hpd ==RADEON_HPD_NONE ) { -if (i2c_bus->valid) - connector->polled =DRM_CONNECTOR_POLL_CONNECT ; +if (i2c_bus->valid) { + connector->polled =DRM_CONNECTOR_POLL_CONNECT | +DRM_CONNECTOR_POLL_DISCONNECT ; + } }else connector->polled =DRM_CONNECTOR_POLL_HPD ; + connector->display_info.subpixel_order = subpixel_order;drm_connector_register (connector); }
Greg Kroah-Hartman
maintainerPATCH 83/138 drm/radeon: fix firmware info version checks
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 3edc38a0facef45ee22af8afdce3737f421f36ab upstream.
Some of the checks didn't handle frev 2 tables properly.
--- drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/radeon/radeon_atombios.c +2 -2
@@ -1155,7 +1155,7 @@ bool radeon_atom_get_clock_info(struct dle16_to_cpu (firmware_info->info.usReferenceClock); p1pll->reference_div =0 ; -if (crev <2 ) +if ((frev <2 ) && (crev <2 )) p1pll->pll_out_min =le16_to_cpu (firmware_info->info.usMinPixelClockPLL_Output);else
@@ -1164,7 +1164,7 @@ bool radeon_atom_get_clock_info(struct d p1pll->pll_out_max =le32_to_cpu (firmware_info->info.ulMaxPixelClockPLL_Output); -if (crev >=4 ) { +if (((frev <2 ) && (crev >=4 )) || (frev >=2 )) { p1pll->lcd_pll_out_min =le16_to_cpu (firmware_info->info_14.usLcdMinPixelClockPLL_Output) *100 ;if (p1pll->lcd_pll_out_min ==0 )
Greg Kroah-Hartman
maintainerPATCH 86/138 drm/nouveau/gr/nv3x: fix instobj write offsets in gr setup
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilia Mirkin <[email protected]>
commit d0e62ef6ed257715a88d0e5d7cd850a1695429e2 upstream.
This should fix some unaligned access warnings. This is also likely to fix non-descript issues on nv30/nv34 as a result of incorrect channel setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836
--- drivers/gpu/drm/nouveau/nvkm/engine/gr/nv30.c | 4 ++-- drivers/gpu/drm/nouveau/nvkm/engine/gr/nv34.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
drivers/gpu/drm/nouveau/nvkm/engine/gr/nv30.c +2 -2
@@ -76,8 +76,8 @@ nv30_gr_chan_new(struct nvkm_gr *base, snvkm_wo32 (chan->inst, i,0x00040004 );for (i =0x1f18 ; i <=0x3088 ; i +=16 ) {nvkm_wo32 (chan->inst, i +0 ,0x10700ff9 ); -nvkm_wo32 (chan->inst, i +1 ,0x0436086c ); -nvkm_wo32 (chan->inst, i +2 ,0x000c001b ); +nvkm_wo32 (chan->inst, i +4 ,0x0436086c ); +nvkm_wo32 (chan->inst, i +8 ,0x000c001b ); }for (i =0x30b8 ; i <0x30c8 ; i +=4 )nvkm_wo32 (chan->inst, i,0x0000ffff );
drivers/gpu/drm/nouveau/nvkm/engine/gr/nv34.c +2 -2
@@ -75,8 +75,8 @@ nv34_gr_chan_new(struct nvkm_gr *base, snvkm_wo32 (chan->inst, i,0x00040004 );for (i =0x15ac ; i <=0x271c ; i +=16 ) {nvkm_wo32 (chan->inst, i +0 ,0x10700ff9 ); -nvkm_wo32 (chan->inst, i +1 ,0x0436086c ); -nvkm_wo32 (chan->inst, i +2 ,0x000c001b ); +nvkm_wo32 (chan->inst, i +4 ,0x0436086c ); +nvkm_wo32 (chan->inst, i +8 ,0x000c001b ); }for (i =0x274c ; i <0x275c ; i +=4 )nvkm_wo32 (chan->inst, i,0x0000ffff );
Greg Kroah-Hartman
maintainerPATCH 87/138 drm/nouveau/fbcon: fix font width not divisible by 8
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <[email protected]>
commit 28668f43b8e421634e1623f72a879812288dd06b upstream.
The patch f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses") tries to fix some out of memory accesses. Unfortunatelly, the patch breaks the display when using fonts with width that is not divisiable by 8.
The monochrome bitmap for each character is stored in memory by lines from top to bottom. Each line is padded to a full byte.
For example, for 22x11 font, each line is padded to 16 bits, so each character is consuming 44 bytes total, that is 11 32-bit words. The patch f045f459d925 changed the logic to "dsize = ALIGN(image->width * image->height, 32) >> 5", that is just 8 words - this is incorrect and it causes display corruption.
This patch adds the necesary padding of lines to 8 bytes.
This patch should be backported to stable kernels where f045f459d925 was backported.
--- drivers/gpu/drm/nouveau/nv04_fbcon.c | 4 ++-- drivers/gpu/drm/nouveau/nv50_fbcon.c | 2 +- drivers/gpu/drm/nouveau/nvc0_fbcon.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-)
drivers/gpu/drm/nouveau/nv04_fbcon.c +2 -2
@@ -107,11 +107,11 @@ nv04_fbcon_imageblit(struct fb_info *inf ((image->dx + image->width) & 0xffff));OUT_RING (chan, bg);OUT_RING (chan, fg); -OUT_RING (chan, (image->height <<16 ) | image->width); +OUT_RING (chan, (image->height <<16 ) |ALIGN (image->width,8 ));OUT_RING (chan, (image->height <<16 ) | image->width);OUT_RING (chan, (image->dy <<16 ) | (image->dx &0xffff )); - dsize =ALIGN (image->width * image->height,32 ) >>5 ; + dsize =ALIGN (ALIGN (image->width,8 ) * image->height,32 ) >>5 ;while (dsize) {int iter_len = dsize >128 ?128 : dsize;
drivers/gpu/drm/nouveau/nv50_fbcon.c +1 -1
@@ -125,7 +125,7 @@ nv50_fbcon_imageblit(struct fb_info *infOUT_RING (chan,0 );OUT_RING (chan, image->dy); - dwords =ALIGN (image->width * image->height,32 ) >>5 ; + dwords =ALIGN (ALIGN (image->width,8 ) * image->height,32 ) >>5 ;while (dwords) {int push = dwords >2047 ?2047 : dwords;
drivers/gpu/drm/nouveau/nvc0_fbcon.c +1 -1
@@ -125,7 +125,7 @@ nvc0_fbcon_imageblit(struct fb_info *infOUT_RING (chan,0 );OUT_RING (chan, image->dy); - dwords =ALIGN (image->width * image->height,32 ) >>5 ; + dwords =ALIGN (ALIGN (image->width,8 ) * image->height,32 ) >>5 ;while (dwords) {int push = dwords >2047 ?2047 : dwords;
Greg Kroah-Hartman
maintainerPATCH 88/138 drm: Restore double clflush on the last partial cacheline
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
commit 396f5d62d1a5fd99421855a08ffdef8edb43c76e upstream.
This effectively reverts
commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
Author: Chris Wilson <[email protected]> Date: Wed Jun 10 15:58:01 2015 +0100
drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range()
as we have observed issues with serialisation of the clflush operations on Baytrail+ Atoms with partial updates. Applying the double flush on the last cacheline forces that clflush to be ordered with respect to the previous clflush, and the mfence then protects against prefetches crossing the clflush boundary.
The same issue can be demonstrated in userspace with igt/gem_exec_flush.
Testcase: igt/gem_concurrent_blit
Testcase: igt/gem_partial_pread_pwrite
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92845
--- drivers/gpu/drm/drm_cache.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/drm_cache.c +1 -0
@@ -136,6 +136,7 @@ drm_clflush_virt_range(void *addr, unsigmb ();for (; addr < end; addr += size)clflushopt (addr); +clflushopt (end -1 );/* force serialisation */ mb ();return ; }
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Greg Kroah-Hartman
maintainerPATCH 92/138 balloon: check the number of available pages in leak balloon
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Neumoin <[email protected]>
commit 37cf99e08c6fb4dcea0f9ad2b13b6daa8c76a711 upstream.
The balloon has a special mechanism that is subscribed to the oom notification which leads to deflation for a fixed number of pages. The number is always fixed even when the balloon is fully deflated. But leak_balloon did not expect that the pages to deflate will be more than taken, and raise a "BUG" in balloon_page_dequeue when page list will be empty.
So, the simplest solution would be to check that the number of releases pages is less or equal to the number taken pages.
--- drivers/virtio/virtio_balloon.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/virtio/virtio_balloon.c +2 -0
@@ -196,6 +196,8 @@ static unsigned leak_balloon(struct virt num =min (num,ARRAY_SIZE (vb->pfns));mutex_lock (&vb->balloon_lock); +/* We can't release more pages than taken */ + num =min (num, (size_t )vb->num_pages);for (vb->num_pfns =0 ; vb->num_pfns < num; vb->num_pfns +=VIRTIO_BALLOON_PAGES_PER_PAGE ) { page =balloon_page_dequeue (vb_dev_info);
Greg Kroah-Hartman
maintainerPATCH 93/138 ftrace/recordmcount: Work around for addition of metag magic but not relocations
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laura Abbott <[email protected]>
commit b2e1c26f0b62531636509fbcb6dab65617ed8331 upstream.
glibc recently did a sync up (94e73c95d9b5 "elf.h: Sync with the gabi webpage") that added a #define for EM_METAG but did not add relocations
This triggers build errors:
scripts/recordmcount.c: In function 'do_file':scripts/recordmcount.c:466:28: error: 'R_METAG_ADDR32' undeclared (first use in this function)
case EM_METAG: reltype = R_METAG_ADDR32;
^~~~~~~~~~~~~~
scripts/recordmcount.c:466:28: note: each undeclared identifier is reported only once for each function it appears in
scripts/recordmcount.c:468:20: error: 'R_METAG_NONE' undeclared (first use in this function)
rel_type_nop = R_METAG_NONE;
^~~~~~~~~~~~Work around this change with some more #ifdefery for the relocations.
Fedora Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1354034
--- scripts/recordmcount.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
scripts/recordmcount.c +8 -1
@@ -33,10 +33,17 @@#include <string.h> #include <unistd.h> +/* +* glibc synced up and added the metag number but didn't add the relocations. +* Work around this in a crude manner for now. +*/ #ifndef EM_METAG -/* Remove this when these make it to the standard system elf.h. */ #define EM_METAG 174 +#endif +#ifndef R_METAG_ADDR32 #define R_METAG_ADDR32 2 +#endif +#ifndef R_METAG_NONE #define R_METAG_NONE 3#endif
Greg Kroah-Hartman
maintainerPATCH 95/138 block: add missing group association in bio-cloning functions
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Valente <[email protected]>
commit 20bd723ec6a3261df5e02250cd3a1fbb09a343f2 upstream.
When a bio is cloned, the newly created bio must be associated with the same blkcg as the original bio (if BLK_CGROUP is enabled). If this operation is not performed, then the new bio is not associated with any group, and the group of the current task is returned when the group of the bio is requested.
Depending on the cloning frequency, this may cause a large percentage of the bios belonging to a given group to be treated as if belonging to other groups (in most cases as if belonging to the root group). The expected group isolation may thereby be broken.
This commit adds the missing association in bio-cloning functions.
--- block/bio.c | 15 +++++++++++++++ fs/btrfs/extent_io.c | 6 ------ include/linux/bio.h | 3 +++ 3 files changed, 18 insertions(+), 6 deletions(-)
block/bio.c +15 -0
@@ -584,6 +584,8 @@ void __bio_clone_fast(struct bio *bio, s bio->bi_rw = bio_src->bi_rw; bio->bi_iter = bio_src->bi_iter; bio->bi_io_vec = bio_src->bi_io_vec; + +bio_clone_blkcg_association (bio, bio_src); }EXPORT_SYMBOL (__bio_clone_fast);
@@ -689,6 +691,8 @@ integrity_clone: } } +bio_clone_blkcg_association (bio, bio_src); +return bio; }EXPORT_SYMBOL (bio_clone_bioset);
@@ -2014,6 +2018,17 @@ void bio_disassociate_task(struct bio *b } } +/** +* bio_clone_blkcg_association - clone blkcg association from src to dst bio +* @dst: destination bio +* @src: source bio +*/ +void bio_clone_blkcg_association (struct bio *dst,struct bio *src) +{ +if (src->bi_css) +WARN_ON (bio_associate_blkcg (dst, src->bi_css)); +} +#endif /* CONFIG_BLK_CGROUP */ static void __init biovec_init_slabs (void )
fs/btrfs/extent_io.c +0 -6
@@ -2786,12 +2786,6 @@ struct bio *btrfs_bio_clone(struct bio * btrfs_bio->csum =NULL ; btrfs_bio->csum_allocated =NULL ; btrfs_bio->end_io =NULL ; - -#ifdef CONFIG_BLK_CGROUP -/* FIXME, put this into bio_clone_bioset */ -if (bio->bi_css) -bio_associate_blkcg (new, bio->bi_css); -#endif }return new; }
include/linux/bio.h +3 -0
@@ -527,11 +527,14 @@ extern unsigned int bvec_nr_vecs(unsigneint bio_associate_blkcg (struct bio *bio,struct cgroup_subsys_state *blkcg_css);int bio_associate_current (struct bio *bio);void bio_disassociate_task (struct bio *bio); +void bio_clone_blkcg_association (struct bio *dst,struct bio *src);#else /* CONFIG_BLK_CGROUP */ static inline int bio_associate_blkcg (struct bio *bio,struct cgroup_subsys_state *blkcg_css) {return 0 ; }static inline int bio_associate_current (struct bio *bio) {return -ENOENT ; }static inline void bio_disassociate_task (struct bio *bio) { } +static inline void bio_clone_blkcg_association (struct bio *dst, +struct bio *src) { }#endif /* CONFIG_BLK_CGROUP */ #ifdef CONFIG_HIGHMEM
Greg Kroah-Hartman
maintainerPATCH 96/138 block: fix bdi vs gendisk lifetime mismatch
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit df08c32ce3be5be138c1dbfcba203314a3a7cd6f upstream.
The name for a bdi of a gendisk is derived from the gendisk's devt. However, since the gendisk is destroyed before the bdi it leaves a window where a new gendisk could dynamically reuse the same devt while a bdi with the same name is still live. Arrange for the bdi to hold a reference against its "owner" disk device while it is registered. Otherwise we can hit sysfs duplicate name collisions like the following:
WARNING: CPU: 10 PID: 2078 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x80 sysfs: cannot create duplicate filename '/devices/virtual/bdi/259:1' Hardware name: HP ProLiant DL580 Gen8, BIOS P79 05/06/2015 0000000000000286 0000000002c04ad5 ffff88006f24f970 ffffffff8134caec ffff88006f24f9c0 0000000000000000 ffff88006f24f9b0 ffffffff8108c351 0000001f0000000c ffff88105d236000 ffff88105d1031e0 ffff8800357427f8 Call Trace: [<ffffffff8134caec>] dump_stack+0x63/0x87 [<ffffffff8108c351>] __warn+0xd1/0xf0 [<ffffffff8108c3cf>] warn_slowpath_fmt+0x5f/0x80 [<ffffffff812a0d34>] sysfs_warn_dup+0x64/0x80 [<ffffffff812a0e1e>] sysfs_create_dir_ns+0x7e/0x90 [<ffffffff8134faaa>] kobject_add_internal+0xaa/0x320 [<ffffffff81358d4e>] ? vsnprintf+0x34e/0x4d0 [<ffffffff8134ff55>] kobject_add+0x75/0xd0 [<ffffffff816e66b2>] ? mutex_lock+0x12/0x2f [<ffffffff8148b0a5>] device_add+0x125/0x610 [<ffffffff8148b788>] device_create_groups_vargs+0xd8/0x100 [<ffffffff8148b7cc>] device_create_vargs+0x1c/0x20 [<ffffffff811b775c>] bdi_register+0x8c/0x180 [<ffffffff811b7877>] bdi_register_dev+0x27/0x30 [<ffffffff813317f5>] add_disk+0x175/0x4a0
Fixed up missing 0 return in bdi_register_owner().
--- block/genhd.c | 2 +- include/linux/backing-dev-defs.h | 1 + include/linux/backing-dev.h | 1 + mm/backing-dev.c | 19 +++++++++++++++++++ 4 files changed, 22 insertions(+), 1 deletion(-)
block/genhd.c +1 -1
@@ -612,7 +612,7 @@ void add_disk(struct gendisk *disk)/* Register BDI before referencing it from bdev */ bdi = &disk->queue->backing_dev_info; -bdi_register_dev (bdi,disk_devt (disk)); +bdi_register_owner (bdi,disk_to_dev (disk));blk_register_region (disk_devt (disk), disk->minors,NULL , exact_match, exact_lock, disk);
include/linux/backing-dev-defs.h +1 -0
@@ -163,6 +163,7 @@ struct backing_dev_info {wait_queue_head_t wb_waitq;struct device *dev; +struct device *owner;struct timer_list laptop_mode_wb_timer;
include/linux/backing-dev.h +1 -0
@@ -24,6 +24,7 @@ __printf(3, 4)int bdi_register (struct backing_dev_info *bdi,struct device *parent,const char *fmt, ...);int bdi_register_dev (struct backing_dev_info *bdi,dev_t dev); +int bdi_register_owner (struct backing_dev_info *bdi,struct device *owner);void bdi_unregister (struct backing_dev_info *bdi);int __must_check bdi_setup_and_register (struct backing_dev_info *,char *);
mm/backing-dev.c +19 -0
@@ -825,6 +825,20 @@ int bdi_register_dev(struct backing_dev_ }EXPORT_SYMBOL (bdi_register_dev); +int bdi_register_owner (struct backing_dev_info *bdi,struct device *owner) +{ +int rc; + + rc =bdi_register (bdi,NULL ,"%u:%u" ,MAJOR (owner->devt), +MINOR (owner->devt)); +if (rc) +return rc; + bdi->owner = owner; +get_device (owner); +return 0 ; +} +EXPORT_SYMBOL (bdi_register_owner); +/* * Remove bdi from bdi_list, and ensure that it is no longer visible */
@@ -849,6 +863,11 @@ void bdi_unregister(struct backing_dev_idevice_unregister (bdi->dev); bdi->dev =NULL ; } + +if (bdi->owner) { +put_device (bdi->owner); + bdi->owner =NULL ; + } }void bdi_exit (struct backing_dev_info *bdi)
Greg Kroah-Hartman
maintainerPATCH 97/138 mtd: nand: fix bug writing 1 byte less than page size
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hector Palacios <[email protected]>
commit 144f4c98399e2c0ca60eb414c15a2c68125c18b8 upstream.
nand_do_write_ops() determines if it is writing a partial page with the formula:
part_pagewr = (column || writelen < (mtd->writesize - 1))
When 'writelen' is exactly 1 byte less than the NAND page size the formula equates to zero, so the code doesn't process it as a partial write, although it should.
As a consequence the function remains in the while(1) loop with 'writelen' becoming 0xffffffff and iterating endlessly.
The bug may not be easy to reproduce in Linux since user space tools usually force the padding or round-up the write size to a page-size multiple.
This was discovered in U-Boot where the issue can be reproduced by writing any size that is 1 byte less than a page-size multiple. For example, on a NAND with 2K page (0x800):
=> nand erase.part <partition>
=> nand write $loadaddr <partition> 7ff
[Editor's note: the bug was added in commit 29072b96078f, but moved around in commit 66507c7bc8895 ("mtd: nand: Add support to use nand_base poi databuf as bounce buffer")]
--- drivers/mtd/nand/nand_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/nand_base.c +1 -1
@@ -2586,7 +2586,7 @@ static int nand_do_write_ops(struct mtd_int cached = writelen > bytes && page != blockmask;uint8_t *wbuf = buf;int use_bufpoi; -int part_pagewr = (column || writelen < (mtd->writesize -1 )); +int part_pagewr = (column || writelen < mtd->writesize);if (part_pagewr) use_bufpoi =1 ;
Greg Kroah-Hartman
maintainerPATCH 98/138 mm/hugetlb: avoid soft lockup in set_max_huge_pages()
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jia He <[email protected]>
commit 649920c6ab93429b94bc7c1aa7c0e8395351be32 upstream.
In powerpc servers with large memory(32TB), we watched several soft lockups for hugepage under stress tests.
The call traces are as follows:
1.
get_page_from_freelist+0x2d8/0xd50 __alloc_pages_nodemask+0x180/0xc20 alloc_fresh_huge_page+0xb0/0x190 set_max_huge_pages+0x164/0x3b0
2.
prep_new_huge_page+0x5c/0x100 alloc_fresh_huge_page+0xc8/0x190 set_max_huge_pages+0x164/0x3b0
This patch fixes such soft lockups. It is safe to call cond_resched() there because it is out of spin_lock/unlock section.
--- mm/hugetlb.c | 4 ++++ 1 file changed, 4 insertions(+)
mm/hugetlb.c +4 -0
@@ -2170,6 +2170,10 @@ static unsigned long set_max_huge_pages(* and reducing the surplus. */ spin_unlock (&hugetlb_lock); + +/* yield cpu to avoid soft lockup */ +cond_resched (); +if (hstate_is_gigantic (h)) ret =alloc_fresh_gigantic_page (h, nodes_allowed);else
Greg Kroah-Hartman
maintainerPATCH 99/138 ALSA: hda: Fix krealloc() with __GFP_ZERO usage
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 33baefe5e72f17a6df378e48196cd8cada11deec upstream.
krealloc() doesn't work always properly with __GFP_ZERO flag as expected. For clearing the reallocated area, we need to clear explicitly instead.
--- sound/hda/array.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
sound/hda/array.c +3 -1
@@ -21,13 +21,15 @@ void *snd_array_new(struct snd_array *arreturn NULL ;if (array->used >= array->alloced) {int num = array->alloced + array->alloc_align; +int oldsize = array->alloced * array->elem_size;int size = (num +1 ) * array->elem_size;void *nlist;if (snd_BUG_ON (num >=4096 ))return NULL ; - nlist =krealloc (array->list, size,GFP_KERNEL | __GFP_ZERO); + nlist =krealloc (array->list, size,GFP_KERNEL );if (!nlist)return NULL ; +memset (nlist + oldsize,0 , size - oldsize); array->list = nlist; array->alloced = num; }
Greg Kroah-Hartman
maintainerPATCH 100/138 ALSA: hda/realtek - Cant adjust speakers volume on a Dell AIO
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hui Wang <[email protected]>
commit dd9aa335c88003d131ac874e7f6809902de0b847 upstream.
We have a Dell AIO on which we can't adjust its speaker's volume. The problem is it is connected to a Audio Output node without Amp-out capability. To fix it, we change it to be connnected to a node with Amp-out capability.
--- sound/pci/hda/patch_realtek.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
sound/pci/hda/patch_realtek.c +22 -0
@@ -4674,6 +4674,22 @@ static void alc290_fixup_mono_speakers(s } } +static void alc298_fixup_speaker_volume (struct hda_codec *codec, +const struct hda_fixup *fix,int action) +{ +if (action ==HDA_FIXUP_ACT_PRE_PROBE ) { +/* The speaker is routed to the Node 0x06 by a mistake, as a result +we can't adjust the speaker's volume since this node does not has +Amp-out capability. we change the speaker's route to: +Node 0x02 (Audio Output) -> Node 0x0c (Audio Mixer) -> Node 0x17 ( +Pin Complex), since Node 0x02 has Amp-out caps, we can adjust +speaker's volume now. */ + +hda_nid_t conn1[1 ] = {0x0c }; +snd_hda_override_conn_list (codec,0x17 ,1 , conn1); + } +} +/* Hook to update amp GPIO4 for automute */ static void alc280_hp_gpio4_automute_hook (struct hda_codec *codec,struct hda_jack_callback *jack)
@@ -4823,6 +4839,7 @@ enum {ALC280_FIXUP_HP_HEADSET_MIC ,ALC221_FIXUP_HP_FRONT_MIC ,ALC292_FIXUP_TPT460 , + ALC298_FIXUP_SPK_VOLUME, }; static const struct hda_fixup alc269_fixups[] = {
@@ -5478,6 +5495,10 @@ static const struct hda_fixup alc269_fix .chained = true, .chain_id = ALC293_FIXUP_LENOVO_SPK_NOISE, }, + [ALC298_FIXUP_SPK_VOLUME] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc298_fixup_speaker_volume, + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -5524,6 +5545,7 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x1028 ,0x0704 ,"Dell XPS 13 9350" ,ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE ),SND_PCI_QUIRK (0x1028 ,0x0725 ,"Dell Inspiron 3162" ,ALC255_FIXUP_DELL_SPK_NOISE ),SND_PCI_QUIRK (0x1028 ,0x075b ,"Dell XPS 13 9360" ,ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE ), +SND_PCI_QUIRK (0x1028 ,0x075d ,"Dell AIO" ,ALC298_FIXUP_SPK_VOLUME ),SND_PCI_QUIRK (0x1028 ,0x164a ,"Dell" ,ALC293_FIXUP_DELL1_MIC_NO_PRESENCE ),SND_PCI_QUIRK (0x1028 ,0x164b ,"Dell" ,ALC293_FIXUP_DELL1_MIC_NO_PRESENCE ), SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2),
Greg Kroah-Hartman
maintainerPATCH 101/138 ALSA: hda: add AMD Bonaire AZ PCI ID with proper driver caps
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maruthi Srinivas Bayyavarapu <[email protected]>
commit fd48331f9b71d2add941adaee3619f5b8527182d upstream.
This commit fixes garbled audio on Bonaire HDMI
--- sound/pci/hda/hda_intel.c | 2 ++ 1 file changed, 2 insertions(+)
sound/pci/hda/hda_intel.c +2 -0
@@ -2288,6 +2288,8 @@ static const struct pci_device_id azx_id { PCI_DEVICE(0x1022, 0x780d), .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, /* ATI HDMI */ + { PCI_DEVICE(0x1002, 0x0002), + .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS }, { PCI_DEVICE(0x1002, 0x1308), .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS }, { PCI_DEVICE(0x1002, 0x157a),
Greg Kroah-Hartman
maintainerPATCH 102/138 ALSA: hda - Fix headset mic detection problem for two dell machines
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hui Wang <[email protected]>
commit 59ec4b57bcaede46546d54d037a21004b9aa5cef upstream.
One of the machines has ALC255 on it, another one has ALC298 on it.
On the machine with the codec ALC298, it also has the speaker volume problem, so we add the fixup chained to ALC298_FIXUP_SPK_VOLUME rather than adding a group of pin definition in the pin quirk table, since the speak volume problem does not happen on other machines yet.
--- sound/pci/hda/patch_realtek.c | 6 ++++++ 1 file changed, 6 insertions(+)
sound/pci/hda/patch_realtek.c +6 -0
@@ -5498,6 +5498,8 @@ static const struct hda_fixup alc269_fix [ALC298_FIXUP_SPK_VOLUME ] = { .type =HDA_FIXUP_FUNC , .v.func = alc298_fixup_speaker_volume, + .chained = true, + .chain_id =ALC298_FIXUP_DELL1_MIC_NO_PRESENCE , }, };
@@ -5821,6 +5823,10 @@ static const struct snd_hda_pin_quirk al {0x1b, 0x01014020}, {0x21, 0x0221103f}),SND_HDA_PIN_QUIRK (0x10ec0255 ,0x1028 ,"Dell" ,ALC255_FIXUP_DELL1_MIC_NO_PRESENCE , + {0x14, 0x90170130}, + {0x1b, 0x02011020}, + {0x21, 0x0221103f}), +SND_HDA_PIN_QUIRK (0x10ec0255 ,0x1028 ,"Dell" ,ALC255_FIXUP_DELL1_MIC_NO_PRESENCE , {0x14, 0x90170150}, {0x1b, 0x02011020}, {0x21, 0x0221105f}),
Greg Kroah-Hartman
maintainerPATCH 103/138 IB/mlx5: Fix MODIFY_QP command input structure
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artemy Kovalyov <[email protected]>
commit e3353c268b06236d6c40fa1714c114f21f44451c upstream.
Make MODIFY_QP command input structure compliant to specification
--- include/linux/mlx5/qp.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
include/linux/mlx5/qp.h +2 -2
@@ -534,9 +534,9 @@ struct mlx5_destroy_qp_mbox_out {struct mlx5_modify_qp_mbox_in {struct mlx5_inbox_hdr hdr;__be32 qpn; -u8 rsvd1[4 ]; -__be32 optparam;u8 rsvd0[4 ]; +__be32 optparam; +u8 rsvd1[4 ];struct mlx5_qp_context ctx; };
Greg Kroah-Hartman
maintainerPATCH 111/138 IB/IWPM: Fix a potential skb leak
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Bloch <[email protected]>
commit 5ed935e861a4cbf2158ad3386d6d26edd60d2658 upstream.
In case ibnl_put_msg fails in send_nlmsg_done, the function returns with -ENOMEM without freeing.
This patch fixes this behavior.
--- drivers/infiniband/core/iwpm_util.c | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/core/iwpm_util.c +1 -0
@@ -634,6 +634,7 @@ static int send_nlmsg_done(struct sk_bufif (!(ibnl_put_msg (skb, &nlh,0 ,0 , nl_client,RDMA_NL_IWPM_MAPINFO ,NLM_F_MULTI ))) {pr_warn ("%s Unable to put NLMSG_DONE\n" , __func__); +dev_kfree_skb (skb);return -ENOMEM ; } nlh->nlmsg_type =NLMSG_DONE ;
Greg Kroah-Hartman
maintainerPATCH 112/138 IB/mlx4: Fix the SQ size of an RC QP
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yishai Hadas <[email protected]>
commit f2940e2c76bb554a7fbdd28ca5b90904117a9e96 upstream.
When calculating the required size of an RC QP send queue, leave enough space for masked atomic operations, which require more space than "regular" atomic operation.
--- drivers/infiniband/hw/mlx4/qp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/hw/mlx4/qp.c +1 -1
@@ -357,7 +357,7 @@ static int send_wqe_overhead(enum mlx4_isizeof (struct mlx4_wqe_raddr_seg );case MLX4_IB_QPT_RC :return sizeof (struct mlx4_wqe_ctrl_seg ) + -sizeof (struct mlx4_wqe_atomic_seg ) + +sizeof (struct mlx4_wqe_masked_atomic_seg ) +sizeof (struct mlx4_wqe_raddr_seg );case MLX4_IB_QPT_SMI :case MLX4_IB_QPT_GSI :
Greg Kroah-Hartman
maintainerPATCH 113/138 IB/mlx4: Fix error flow when sending mads under SRIOV
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yishai Hadas <[email protected]>
commit a6100603a4a87fc436199362bdb81cb849faaf6e upstream.
Fix mad send error flow to prevent double freeing address handles, and leaking tx_ring entries when SRIOV is active.
If ib_mad_post_send fails, the address handle pointer in the tx_ring entry must be set to NULL (or there will be a double-free) and tx_tail must be incremented (or there will be a leak of tx_ring entries).
The tx_ring is handled the same way in the send-completion handler.
--- drivers/infiniband/hw/mlx4/mad.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-)
drivers/infiniband/hw/mlx4/mad.c +18 -6
@@ -526,7 +526,7 @@ int mlx4_ib_send_to_slave(struct mlx4_ib tun_tx_ix = (++tun_qp->tx_ix_head) & (MLX4_NUM_TUNNEL_BUFS -1 );spin_unlock (&tun_qp->tx_lock);if (ret) - goto out; + goto end; tun_mad = (struct mlx4_rcv_tunnel_mad *) (tun_qp->tx_ring[tun_tx_ix].buf.addr);if (tun_qp->tx_ring[tun_tx_ix].ah)
@@ -595,9 +595,15 @@ int mlx4_ib_send_to_slave(struct mlx4_ib wr.wr.send_flags =IB_SEND_SIGNALED ; ret =ib_post_send (src_qp, &wr.wr, &bad_wr); -out: -if (ret) -ib_destroy_ah (ah); +if (!ret) +return 0 ; + out: +spin_lock (&tun_qp->tx_lock); + tun_qp->tx_ix_tail++; +spin_unlock (&tun_qp->tx_lock); + tun_qp->tx_ring[tun_tx_ix].ah =NULL ; +end: +ib_destroy_ah (ah);return ret; }
@@ -1278,9 +1284,15 @@ int mlx4_ib_send_to_wire(struct mlx4_ib_ ret =ib_post_send (send_qp, &wr.wr, &bad_wr); +if (!ret) +return 0 ; + +spin_lock (&sqp->tx_lock); + sqp->tx_ix_tail++; +spin_unlock (&sqp->tx_lock); + sqp->tx_ring[wire_tx_ix].ah =NULL ; out: -if (ret) -ib_destroy_ah (ah); +ib_destroy_ah (ah);return ret; }
Greg Kroah-Hartman
maintainerPATCH 114/138 IB/mlx4: Fix memory leak if QP creation failed
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dotan Barak <[email protected]>
commit 5b420d9cf7382c6e1512e96e02d18842d272049c upstream.
When RC, UC, or RAW QPs are created, a qp object is allocated (kzalloc). If at a later point (in procedure create_qp_common) the qp creation fails, this qp object must be freed.
--- drivers/infiniband/hw/mlx4/qp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/infiniband/hw/mlx4/qp.c +3 -1
@@ -1162,8 +1162,10 @@ struct ib_qp *mlx4_ib_create_qp(struct i { err =create_qp_common (to_mdev (pd->device), pd, init_attr, udata,0 , &qp, gfp); -if (err) +if (err) { +kfree (qp);return ERR_PTR (err); + } qp->ibqp.qp_num = qp->mqp.qpn; qp->xrcdn = xrcdn;
Greg Kroah-Hartman
maintainerPATCH 116/138 ubi: Make volume resize power cut aware
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Weinberger <[email protected]>
commit 4946784bd3924b1374f05eebff2fd68660bae866 upstream.
When the volume resize operation shrinks a volume, LEBs will be unmapped. Since unmapping will not erase these LEBs immediately we have to wait for that operation to finish. Otherwise in case of a power cut right after writing the new volume table the UBI attach process can find more LEBs than the volume table knows. This will render the UBI image unattachable.
Fix this issue by waiting for erase to complete and write the new volume table afterward.
--- drivers/mtd/ubi/vmt.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-)
drivers/mtd/ubi/vmt.c +18 -7
@@ -488,13 +488,6 @@ int ubi_resize_volume(struct ubi_volume_spin_unlock (&ubi->volumes_lock); } -/* Change volume table record */ - vtbl_rec = ubi->vtbl[vol_id]; - vtbl_rec.reserved_pebs =cpu_to_be32 (reserved_pebs); - err =ubi_change_vtbl_record (ubi, vol_id, &vtbl_rec); -if (err) - goto out_acc; -if (pebs <0 ) {for (i =0 ; i < -pebs; i++) { err =ubi_eba_unmap_leb (ubi, vol, reserved_pebs + i);
@@ -512,6 +505,24 @@ int ubi_resize_volume(struct ubi_volume_spin_unlock (&ubi->volumes_lock); } +/* +* When we shrink a volume we have to flush all pending (erase) work. +* Otherwise it can happen that upon next attach UBI finds a LEB with +* lnum > highest_lnum and refuses to attach. +*/ +if (pebs <0 ) { + err =ubi_wl_flush (ubi, vol_id,UBI_ALL ); +if (err) + goto out_acc; + } + +/* Change volume table record */ + vtbl_rec = ubi->vtbl[vol_id]; + vtbl_rec.reserved_pebs =cpu_to_be32 (reserved_pebs); + err =ubi_change_vtbl_record (ubi, vol_id, &vtbl_rec); +if (err) + goto out_acc; + vol->reserved_pebs = reserved_pebs;if (vol->vol_type ==UBI_DYNAMIC_VOLUME ) { vol->used_ebs = reserved_pebs;
Greg Kroah-Hartman
maintainerPATCH 117/138 ubi: Fix early logging
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Weinberger <[email protected]>
commit bc743f34dfa011e62edd0ea4ae8455be06c083b5 upstream.
We cannot use ubi_* logging functions before the UBI object is initialized.
--- drivers/mtd/ubi/build.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/mtd/ubi/build.c +4 -4
@@ -869,7 +869,7 @@ int ubi_attach_mtd_dev(struct mtd_info *for (i =0 ; i <UBI_MAX_DEVICES ; i++) { ubi = ubi_devices[i];if (ubi && mtd->index == ubi->mtd->index) { -ubi_err (ubi,"mtd%d is already attached to ubi%d" , +pr_err ("ubi: mtd%d is already attached to ubi%d" , mtd->index, i);return -EEXIST ; }
@@ -884,7 +884,7 @@ int ubi_attach_mtd_dev(struct mtd_info ** no sense to attach emulated MTD devices, so we prohibit this. */ if (mtd->type ==MTD_UBIVOLUME ) { -ubi_err (ubi,"refuse attaching mtd%d - it is already emulated on top of UBI" , +pr_err ("ubi: refuse attaching mtd%d - it is already emulated on top of UBI" , mtd->index);return -EINVAL ; }
@@ -895,7 +895,7 @@ int ubi_attach_mtd_dev(struct mtd_info *if (!ubi_devices[ubi_num])break ;if (ubi_num ==UBI_MAX_DEVICES ) { -ubi_err (ubi,"only %d UBI devices may be created" , +pr_err ("ubi: only %d UBI devices may be created" ,UBI_MAX_DEVICES );return -ENFILE ; }
@@ -905,7 +905,7 @@ int ubi_attach_mtd_dev(struct mtd_info */* Make sure ubi_num is not busy */ if (ubi_devices[ubi_num]) { -ubi_err (ubi,"already exists" ); +pr_err ("ubi: ubi%i already exists" , ubi_num);return -EEXIST ; } }
Greg Kroah-Hartman
maintainerPATCH 124/138 target: Fix ordered task CHECK_CONDITION early exception handling
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Bellinger <[email protected]>
commit 410c29dfbfdf73d0d0b5d14a21868ab038eca703 upstream.
If a Simple command is sent with a failure, target_setup_cmd_from_cdb returns with TCM_UNSUPPORTED_SCSI_OPCODE or TCM_INVALID_CDB_FIELD.
So in the cases where target_setup_cmd_from_cdb returns an error, we never get far enough to call target_execute_cmd to increment simple_cmds. Since simple_cmds isn't incremented, the result of the failure from target_setup_cmd_from_cdb causes transport_generic_request_failure to decrement simple_cmds, due to call to transport_complete_task_attr.
With this dev->simple_cmds or dev->dev_ordered_sync is now -1, not 0. So when a subsequent command with an Ordered Task is sent, it causes a hang, since dev->simple_cmds is at -1.
--- drivers/target/target_core_transport.c | 7 ++++++- include/target/target_core_base.h | 1 + 2 files changed, 7 insertions(+), 1 deletion(-)
drivers/target/target_core_transport.c +6 -1
@@ -1815,6 +1815,8 @@ static bool target_handle_task_attr(struif (dev->transport->transport_flags &TRANSPORT_FLAG_PASSTHROUGH )return false; + cmd->se_cmd_flags |=SCF_TASK_ATTR_SET ; +/* * Check for the existence of HEAD_OF_QUEUE, and if true return 1 * to allow the passed struct se_cmd list of tasks to the front of the list.
@@ -1937,6 +1939,9 @@ static void transport_complete_task_attrif (dev->transport->transport_flags &TRANSPORT_FLAG_PASSTHROUGH )return ; +if (!(cmd->se_cmd_flags &SCF_TASK_ATTR_SET )) + goto restart; +if (cmd->sam_task_attr ==TCM_SIMPLE_TAG ) {atomic_dec_mb (&dev->simple_cmds); dev->dev_cur_ordered_id++;
@@ -1953,7 +1958,7 @@ static void transport_complete_task_attrpr_debug ("Incremented dev_cur_ordered_id: %u for ORDERED\n" , dev->dev_cur_ordered_id); } - +restart:target_restart_delayed_cmds (dev); }
include/target/target_core_base.h +1 -0
@@ -139,6 +139,7 @@ enum se_cmd_flags_table {SCF_COMPARE_AND_WRITE_POST =0x00100000 ,SCF_PASSTHROUGH_PROT_SG_TO_MEM_NOALLOC =0x00200000 ,SCF_ACK_KREF =0x00400000 , + SCF_TASK_ATTR_SET = 0x01000000, };/* struct se_dev_entry->lun_flags and struct se_lun->lun_access */
Greg Kroah-Hartman
maintainerPATCH 125/138 Input: elan_i2c - properly wake up touchpad on ASUS laptops
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: KT Liao <[email protected]>
commit 2de4fcc64685def3e586856a2dc636df44532395 upstream.
Some ASUS laptops were shipped with touchpads that require to be woken up first, before trying to switch them into absolute reporting mode, otherwise touchpad would fail to work while flooding the logs with:
elan_i2c i2c-ELAN1000:00: invalid report id data (1)
Among affected devices are Asus E202SA, N552VW, X456UF, UX305CA, and others. We detect such devices by checking the IC type and product ID numbers and adjusting order of operations accordingly.
--- drivers/input/mouse/elan_i2c_core.c | 79 ++++++++++++++++++++++++++++-------- 1 file changed, 63 insertions(+), 16 deletions(-)
drivers/input/mouse/elan_i2c_core.c +63 -16
@@ -4,7 +4,8 @@* Copyright (c) 2013 ELAN Microelectronics Corp. * * Author: 林政維 (Duson Lin) <[email protected]> -* Version: 1.6.0 +* Author: KT Liao <[email protected]> +* Version: 1.6.2 * * Based on cyapa driver: * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
@@ -40,7 +41,7 @@#include "elan_i2c.h" #define DRIVER_NAME "elan_i2c" -#define ELAN_DRIVER_VERSION "1.6.1" +#define ELAN_DRIVER_VERSION "1.6.2"#define ELAN_VENDOR_ID 0x04f3#define ETP_MAX_PRESSURE 255#define ETP_FWIDTH_REDUCE 90
@@ -199,9 +200,41 @@ static int elan_sleep(struct elan_tp_datreturn error; } +static int elan_query_product (struct elan_tp_data *data) +{ +int error; + + error = data->ops->get_product_id (data->client, &data->product_id); +if (error) +return error; + + error = data->ops->get_sm_version (data->client, &data->ic_type, + &data->sm_version); +if (error) +return error; + +return 0 ; +} + +static int elan_check_ASUS_special_fw (struct elan_tp_data *data) +{ +if (data->ic_type !=0x0E ) +return false; + +switch (data->product_id) { + case 0x05 ... 0x07: +case 0x09 : +case 0x13 : +return true; +default : +return false; + } +} +static int __elan_initialize (struct elan_tp_data *data) {struct i2c_client *client = data->client; +bool woken_up = false;int error; error = data->ops->initialize (client);
@@ -210,6 +243,27 @@ static int __elan_initialize(struct elanreturn error; } + error =elan_query_product (data); +if (error) +return error; + +/* +* Some ASUS devices were shipped with firmware that requires +* touchpads to be woken up first, before attempting to switch +* them into absolute reporting mode. +*/ +if (elan_check_ASUS_special_fw (data)) { + error = data->ops->sleep_control (client, false); +if (error) { +dev_err (&client->dev, +"failed to wake device up: %d\n" , error); +return error; + } + +msleep (200 ); + woken_up = true; + } + data->mode |=ETP_ENABLE_ABS ; error = data->ops->set_mode (client, data->mode);if (error) {
@@ -218,11 +272,13 @@ static int __elan_initialize(struct elanreturn error; } - error = data->ops->sleep_control (client, false); -if (error) { -dev_err (&client->dev, -"failed to wake device up: %d\n" , error); -return error; +if (!woken_up) { + error = data->ops->sleep_control (client, false); +if (error) { +dev_err (&client->dev, +"failed to wake device up: %d\n" , error); +return error; + } }return 0 ;
@@ -248,10 +304,6 @@ static int elan_query_device_info(struct {int error; - error = data->ops->get_product_id (data->client, &data->product_id); -if (error) -return error; - error = data->ops->get_version (data->client, false, &data->fw_version);if (error)return error;
@@ -261,11 +313,6 @@ static int elan_query_device_info(structif (error)return error; - error = data->ops->get_sm_version (data->client, &data->ic_type, - &data->sm_version); -if (error) -return error; - error = data->ops->get_version (data->client, true, &data->iap_version);if (error)return error;
Greg Kroah-Hartman
maintainerPATCH 127/138 SUNRPC: Dont allocate a full sockaddr_storage for tracing
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit db1bb44c4c7e8d49ed674dc59e5222d99c698088 upstream.
We're always tracing IPv4 or IPv6 addresses, so we can save a lot of space on the ringbuffer by allocating the correct sockaddr size.
--- include/trace/events/sunrpc.h | 47 ++++++++++++++++++++++++++++++------------ 1 file changed, 34 insertions(+), 13 deletions(-)
include/trace/events/sunrpc.h +34 -13
@@ -529,20 +529,27 @@ TRACE_EVENT(svc_xprt_do_enqueue,TP_STRUCT__entry (__field (struct svc_xprt *,xprt ) - __field_struct(struct sockaddr_storage, ss)__field (int, pid) __field(unsigned long, flags) + __dynamic_array(unsigned char, addr, xprt != NULL ? + xprt->xpt_remotelen : 0) ),TP_fast_assign ( __entry->xprt = xprt; - xprt ?memcpy (&__entry->ss, &xprt->xpt_remote,sizeof (__entry->ss)) :memset (&__entry->ss,0 ,sizeof (__entry->ss)); __entry->pid = rqst? rqst->rq_task->pid :0 ; - __entry->flags = xprt ? xprt->xpt_flags :0 ; +if (xprt) { +memcpy (__get_dynamic_array (addr), + &xprt->xpt_remote, + xprt->xpt_remotelen); + __entry->flags = xprt->xpt_flags; + }else + __entry->flags =0 ; ),TP_printk ("xprt=0x%p addr=%pIScp pid=%d flags=%s" , __entry->xprt, - (struct sockaddr *)&__entry->ss, +__get_dynamic_array_len (addr) !=0 ? + (struct sockaddr *)__get_dynamic_array (addr) :NULL , __entry->pid,show_svc_xprt_flags (__entry->flags)) );
@@ -553,18 +560,25 @@ TRACE_EVENT(svc_xprt_dequeue,TP_STRUCT__entry (__field (struct svc_xprt *,xprt ) - __field_struct(struct sockaddr_storage, ss) __field(unsigned long, flags) + __dynamic_array(unsigned char, addr, xprt != NULL ? + xprt->xpt_remotelen : 0) ),TP_fast_assign ( - __entry->xprt = xprt, - xprt ? memcpy(&__entry->ss, &xprt->xpt_remote, sizeof(__entry->ss)) : memset(&__entry->ss, 0, sizeof(__entry->ss)); - __entry->flags = xprt ? xprt->xpt_flags :0 ; + __entry->xprt = xprt; +if (xprt) { +memcpy (__get_dynamic_array (addr), + &xprt->xpt_remote, + xprt->xpt_remotelen); + __entry->flags = xprt->xpt_flags; + }else + __entry->flags =0 ; ),TP_printk ("xprt=0x%p addr=%pIScp flags=%s" , __entry->xprt, - (struct sockaddr *)&__entry->ss, +__get_dynamic_array_len (addr) !=0 ? + (struct sockaddr *)__get_dynamic_array (addr) :NULL ,show_svc_xprt_flags (__entry->flags)) );
@@ -592,19 +606,26 @@ TRACE_EVENT(svc_handle_xprt,TP_STRUCT__entry (__field (struct svc_xprt *,xprt )__field (int, len) - __field_struct(struct sockaddr_storage, ss) __field(unsigned long, flags) + __dynamic_array(unsigned char, addr, xprt != NULL ? + xprt->xpt_remotelen : 0) ),TP_fast_assign ( __entry->xprt = xprt; - xprt ?memcpy (&__entry->ss, &xprt->xpt_remote,sizeof (__entry->ss)) :memset (&__entry->ss,0 ,sizeof (__entry->ss)); __entry->len = len; - __entry->flags = xprt ? xprt->xpt_flags :0 ; +if (xprt) { +memcpy (__get_dynamic_array (addr), + &xprt->xpt_remote, + xprt->xpt_remotelen); + __entry->flags = xprt->xpt_flags; + }else + __entry->flags =0 ; ),TP_printk ("xprt=0x%p addr=%pIScp len=%d flags=%s" , __entry->xprt, - (struct sockaddr *)&__entry->ss, +__get_dynamic_array_len (addr) !=0 ? + (struct sockaddr *)__get_dynamic_array (addr) :NULL , __entry->len,show_svc_xprt_flags (__entry->flags)) );#endif /* _TRACE_SUNRPC_H */
Greg Kroah-Hartman
maintainerPATCH 128/138 MIPS: mm: Fix definition of R6 cache instruction
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Redfearn <[email protected]>
commit 4f53989b0652ffe2605221c81ca8ffcfc90aed2a upstream.
Commit a168b8f1cde6 ("MIPS: mm: Add MIPS R6 instruction encodings") added an incorrect definition of the redefined MIPSr6 cache instruction.
Executing any kernel code including this instuction results in a reserved instruction exception and kernel panic.
Fix the instruction definition.
Patchwork: https://patchwork.linux-mips.org/patch/13663/
--- arch/mips/mm/uasm-mips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/mm/uasm-mips.c +1 -1
@@ -65,7 +65,7 @@ static struct insn insn_table[] = { #ifndef CONFIG_CPU_MIPSR6 { insn_cache, M(cache_op, 0, 0, 0, 0, 0), RS | RT | SIMM }, #else - { insn_cache, M6(cache_op, 0, 0, 0, cache6_op), RS | RT | SIMM9 }, + { insn_cache, M6(spec3_op, 0, 0, 0, cache6_op), RS | RT | SIMM9 }, #endif { insn_daddiu, M(daddiu_op, 0, 0, 0, 0, 0), RS | RT | SIMM }, { insn_daddu, M(spec_op, 0, 0, 0, 0, daddu_op), RS | RT | RD },
Greg Kroah-Hartman
maintainerPATCH 129/138 MIPS: Dont register r4k sched clock when CPUFREQ enabled
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit 07d69579e7fec27e371296d8ca9d6076fc401b5c upstream.
Don't register r4k sched clock when CPUFREQ enabled because sched clock need a constant frequency.
Patchwork: https://patchwork.linux-mips.org/patch/13820/
--- arch/mips/kernel/csrc-r4k.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/mips/kernel/csrc-r4k.c +3 -1
@@ -23,7 +23,7 @@ static struct clocksource clocksource_mi .flags = CLOCK_SOURCE_IS_CONTINUOUS, }; -static u64 notrace r4k_read_sched_clock(void) +static u64 __maybe_unused notrace r4k_read_sched_clock(void) {return read_c0_count (); }
@@ -82,7 +82,9 @@ int __init init_r4k_clocksource(void)clocksource_register_hz (&clocksource_mips, mips_hpt_frequency); +#ifndef CONFIG_CPU_FREQ sched_clock_register (r4k_read_sched_clock,32 , mips_hpt_frequency); +#endif return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 130/138 MIPS: hpet: Increase HPET_MIN_PROG_DELTA and decrease HPET_MIN_CYCLES
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit 3ef06653987d4c4536b408321edf0e5caa2a317f upstream.
At first, we prefer to use mips clockevent device, so we decrease the rating of hpet clockevent device.
For hpet, if HPET_MIN_PROG_DELTA (minimum delta of hpet programming) is too small and HPET_MIN_CYCLES (threshold of -ETIME checking) is too large, then hpet_next_event() can easily return -ETIME. After commit c6eb3f70d44828 ("hrtimer: Get rid of hrtimer softirq") this will cause a RCU stall.
So, HPET_MIN_PROG_DELTA must be sufficient that we don't re-trip the -ETIME check -- if we do, we will return -ETIME, forward the next event time, try to set it, return -ETIME again, and basically lock the system up. Meanwhile, HPET_MIN_CYCLES doesn't need to be too large, 16 cycles is enough.
This solution is similar to commit f9eccf24615672 ("clocksource/drivers /vt8500: Increase the minimum delta").
By the way, this patch ensures hpet count/compare to be 32-bit long.
Patchwork: https://patchwork.linux-mips.org/patch/13819/
--- arch/mips/loongson64/loongson-3/hpet.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
arch/mips/loongson64/loongson-3/hpet.c +7 -7
@@ -13,8 +13,8 @@#define SMBUS_PCI_REG64 0x64#define SMBUS_PCI_REGB4 0xb4 -#define HPET_MIN_CYCLES 64 -#define HPET_MIN_PROG_DELTA (HPET_MIN_CYCLES + (HPET_MIN_CYCLES >> 1)) +#define HPET_MIN_CYCLES 16 +#define HPET_MIN_PROG_DELTA (HPET_MIN_CYCLES * 12)static DEFINE_SPINLOCK (hpet_lock); DEFINE_PER_CPU(struct clock_event_device, hpet_clockevent_device);
@@ -157,14 +157,14 @@ static int hpet_tick_resume(struct clockstatic int hpet_next_event (unsigned long delta,struct clock_event_device *evt) { -unsigned int cnt; -int res; +u32 cnt; +s32 res; cnt =hpet_read (HPET_COUNTER ); - cnt += delta; + cnt += (u32 ) delta;hpet_write (HPET_T0_CMP , cnt); - res = (int )(cnt -hpet_read (HPET_COUNTER )); + res = (s32)(cnt -hpet_read (HPET_COUNTER ));return res <HPET_MIN_CYCLES ? -ETIME :0 ; }
@@ -230,7 +230,7 @@ void __init setup_hpet_timer(void) cd = &per_cpu (hpet_clockevent_device, cpu); cd->name ="hpet" ; - cd->rating =320 ; + cd->rating =100 ; cd->features =CLOCK_EVT_FEAT_PERIODIC |CLOCK_EVT_FEAT_ONESHOT ; cd->set_state_shutdown = hpet_set_state_shutdown; cd->set_state_periodic = hpet_set_state_periodic;
Greg Kroah-Hartman
maintainerPATCH 133/138 ACPI / EC: Work around method reentrancy limit in ACPICA for _Qxx
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lv Zheng <[email protected]>
commit e1191bd4f62d9086a1a47adc286e7fcffc1fa55c upstream.
A regression is caused by the following commit:
Commit: 02b771b64b73226052d6e731a0987db3b47281e9
Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations
In this commit, using system workqueue causes that the maximum parallel executions of _Qxx can exceed 255. This violates the method reentrancy limit in ACPICA and generates the following error log:
ACPI Error: Method reached maximum reentrancy limit (255) (20150818/dsmethod-341)
This patch creates a seperate workqueue and limits the number of parallel _Qxx evaluations down to a configurable value (can be tuned against number of online CPUs).
Since EC events are handled after driver probe, we can create the workqueue in acpi_ec_init().
--- drivers/acpi/ec.c | 41 +++++++++++++++++++++++++++++++++++++---- 1 file changed, 37 insertions(+), 4 deletions(-)
drivers/acpi/ec.c +37 -4
@@ -101,6 +101,7 @@ enum ec_command {#define ACPI_EC_UDELAY_POLL 550/* Wait 1ms for EC transaction polling */ #define ACPI_EC_CLEAR_MAX 100/* Maximum number of events to query * when trying to clear the EC */ +#define ACPI_EC_MAX_QUERIES 16/* Maximum number of parallel queries */ enum {EC_FLAGS_QUERY_PENDING ,/* Query is pending */
@@ -121,6 +122,10 @@ static unsigned int ec_delay __read_mostmodule_param (ec_delay, uint,0644 );MODULE_PARM_DESC (ec_delay,"Timeout(ms) waited until an EC command completes" ); +static unsigned int ec_max_queries__read_mostly =ACPI_EC_MAX_QUERIES ; +module_param (ec_max_queries, uint,0644 ); +MODULE_PARM_DESC (ec_max_queries,"Maximum parallel _Qxx evaluations" ); +static bool ec_busy_polling__read_mostly ;module_param (ec_busy_polling, bool,0644 );MODULE_PARM_DESC (ec_busy_polling,"Use busy polling to advance EC transaction" );
@@ -174,6 +179,7 @@ static void acpi_ec_event_processor(strustruct acpi_ec *boot_ec, *first_ec;EXPORT_SYMBOL (first_ec); +static struct workqueue_struct *ec_query_wq;static int EC_FLAGS_VALIDATE_ECDT ;/* ASUStec ECDTs need to be validated */ static int EC_FLAGS_SKIP_DSDT_SCAN ;/* Not all BIOS survive early DSDT scan */
@@ -1097,7 +1103,7 @@ static int acpi_ec_query(struct acpi_ec* work queue execution. */ ec_dbg_evt ("Query(0x%02x) scheduled" , value); -if (!schedule_work (&q->work)) { +if (!queue_work (ec_query_wq, &q->work)) {ec_dbg_evt ("Query(0x%02x) overlapped" , value); result = -EBUSY ; }
@@ -1657,15 +1663,41 @@ static struct acpi_driver acpi_ec_driver }, }; +static inline int acpi_ec_query_init (void ) +{ +if (!ec_query_wq) { + ec_query_wq =alloc_workqueue ("kec_query" ,0 , + ec_max_queries); +if (!ec_query_wq) +return -ENODEV ; + } +return 0 ; +} + +static inline void acpi_ec_query_exit (void ) +{ +if (ec_query_wq) { +destroy_workqueue (ec_query_wq); + ec_query_wq =NULL ; + } +} +int __init acpi_ec_init (void ) { -int result =0 ; +int result; +/* register workqueue for _Qxx evaluations */ + result =acpi_ec_query_init (); +if (result) + goto err_exit;/* Now register the driver for the EC */ result =acpi_bus_register_driver (&acpi_ec_driver); -if (result <0 ) -return -ENODEV ; +if (result) + goto err_exit; +err_exit: +if (result) +acpi_ec_query_exit ();return result; }
@@ -1675,5 +1707,6 @@ static void __exit acpi_ec_exit(void) {acpi_bus_unregister_driver (&acpi_ec_driver); +acpi_ec_query_exit (); }#endif /* 0 */
Greg Kroah-Hartman
maintainerPATCH 134/138 lpfc: fix oops in lpfc_sli4_scmd_to_wqidx_distr() from lpfc_send_taskmgmt()
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauricio Faria de Oliveira <[email protected]>
commit 05a05872c8d4b4357c9d913e6d73ae64882bddf5 upstream.
The lpfc_sli4_scmd_to_wqidx_distr() function expects the scsi_cmnd 'lpfc_cmd->pCmd' not to be null, and point to the midlayer command.
That's not true in the .eh_(device|target|bus)_reset_handler path, because lpfc_send_taskmgmt() sends commands not from the midlayer, so does not set 'lpfc_cmd->pCmd'.
That is true in the .queuecommand path because lpfc_queuecommand() stores the scsi_cmnd from midlayer in lpfc_cmd->pCmd; and lpfc_cmd is stored by lpfc_scsi_prep_cmnd() in piocbq->context1 -- which is passed to lpfc_sli4_scmd_to_wqidx_distr() as lpfc_cmd parameter.
This problem can be hit on SCSI EH, and immediately with sg_reset. These 2 test-cases demonstrate the problem/fix with next-20160601.
Test-case 1) sg_reset
# strace sg_reset --device /dev/sdm
<...>
open("/dev/sdm", O_RDWR|O_NONBLOCK) = 3
ioctl(3, SG_SCSI_RESET, 0x3fffde6d0994 <unfinished ...>
+++ killed by SIGSEGV +++
Segmentation fault # dmesg
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xd00000001c88442c
Oops: Kernel access of bad area, sig: 11 [#1]
<...>
CPU: 104 PID: 16333 Comm: sg_reset Tainted: G W 4.7.0-rc1-next-20160601-00004-g95b89dc #6
<...>
NIP [d00000001c88442c] lpfc_sli4_scmd_to_wqidx_distr+0xc/0xd0 [lpfc]
LR [d00000001c826fe8] lpfc_sli_calc_ring.part.27+0x98/0xd0 [lpfc]
Call Trace:
[c000003c9ec876f0] [c000003c9ec87770] 0xc000003c9ec87770 (unreliable)
[c000003c9ec87720] [d00000001c82e004] lpfc_sli_issue_iocb+0xd4/0x260 [lpfc]
[c000003c9ec87780] [d00000001c831a3c] lpfc_sli_issue_iocb_wait+0x15c/0x5b0 [lpfc]
[c000003c9ec87880] [d00000001c87f27c] lpfc_send_taskmgmt+0x24c/0x650 [lpfc]
[c000003c9ec87950] [d00000001c87fd7c] lpfc_device_reset_handler+0x10c/0x200 [lpfc]
[c000003c9ec87a10] [c000000000610694] scsi_try_bus_device_reset+0x44/0xc0
[c000003c9ec87a40] [c0000000006113e8] scsi_ioctl_reset+0x198/0x2c0
[c000003c9ec87bf0] [c00000000060fe5c] scsi_ioctl+0x13c/0x4b0
[c000003c9ec87c80] [c0000000006629b0] sd_ioctl+0xf0/0x120
[c000003c9ec87cd0] [c00000000046e4f8] blkdev_ioctl+0x248/0xb70
[c000003c9ec87d30] [c0000000002a1f60] block_ioctl+0x70/0x90
[c000003c9ec87d50] [c00000000026d334] do_vfs_ioctl+0xc4/0x890
[c000003c9ec87de0] [c00000000026db60] SyS_ioctl+0x60/0xc0
[c000003c9ec87e30] [c000000000009120] system_call+0x38/0x108
Instruction dump:
<...> With fix:
# strace sg_reset --device /dev/sdm
<...>
open("/dev/sdm", O_RDWR|O_NONBLOCK) = 3
ioctl(3, SG_SCSI_RESET, 0x3fffe103c554) = 0
close(3) = 0
exit_group(0) = ?
+++ exited with 0 +++
# dmesg
[ 424.658649] lpfc 0006:01:00.4: 4:(0):0713 SCSI layer issued Device Reset (1, 0) return x2002Test-case 2) SCSI EH
Using this debug patch to wire an SCSI EH trigger, for lpfc_scsi_cmd_iocb_cmpl():
- cmd->scsi_done(cmd);
+ if ((phba->pport ? phba->pport->cfg_log_verbose : phba->cfg_log_verbose) == 0x32100000)
+ printk(KERN_ALERT "lpfc: skip scsi_done()\n");
+ else
+ cmd->scsi_done(cmd);
# echo 0x32100000 > /sys/class/scsi_host/host11/lpfc_log_verbose
# dd if=/dev/sdm of=/dev/null iflag=direct &
<...>
After a while:
# dmesg
lpfc 0006:01:00.4: 4:(0):3053 lpfc_log_verbose changed from 0 (x0) to 839909376 (x32100000)
lpfc: skip scsi_done()
<...>
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xd0000000199e448c
Oops: Kernel access of bad area, sig: 11 [#1]
<...>
CPU: 96 PID: 28556 Comm: scsi_eh_11 Tainted: G W 4.7.0-rc1-next-20160601-00004-g95b89dc #6
<...>
NIP [d0000000199e448c] lpfc_sli4_scmd_to_wqidx_distr+0xc/0xd0 [lpfc]
LR [d000000019986fe8] lpfc_sli_calc_ring.part.27+0x98/0xd0 [lpfc]
Call Trace:
[c000000ff0d0b890] [c000000ff0d0b900] 0xc000000ff0d0b900 (unreliable)
[c000000ff0d0b8c0] [d00000001998e004] lpfc_sli_issue_iocb+0xd4/0x260 [lpfc]
[c000000ff0d0b920] [d000000019991a3c] lpfc_sli_issue_iocb_wait+0x15c/0x5b0 [lpfc]
[c000000ff0d0ba20] [d0000000199df27c] lpfc_send_taskmgmt+0x24c/0x650 [lpfc]
[c000000ff0d0baf0] [d0000000199dfd7c] lpfc_device_reset_handler+0x10c/0x200 [lpfc]
[c000000ff0d0bbb0] [c000000000610694] scsi_try_bus_device_reset+0x44/0xc0
[c000000ff0d0bbe0] [c0000000006126cc] scsi_eh_ready_devs+0x49c/0x9c0
[c000000ff0d0bcb0] [c000000000614160] scsi_error_handler+0x580/0x680
[c000000ff0d0bd80] [c0000000000ae848] kthread+0x108/0x130
[c000000ff0d0be30] [c0000000000094a8] ret_from_kernel_thread+0x5c/0xb4
Instruction dump:
<...>
With fix:
# dmesg
lpfc 0006:01:00.4: 4:(0):3053 lpfc_log_verbose changed from 0 (x0) to 839909376 (x32100000)
lpfc: skip scsi_done()
<...>
lpfc 0006:01:00.4: 4:(0):0713 SCSI layer issued Device Reset (0, 0) return x2002
<...>
lpfc 0006:01:00.4: 4:(0):0723 SCSI layer issued Target Reset (1, 0) return x2002
<...>
lpfc 0006:01:00.4: 4:(0):0714 SCSI layer issued Bus Reset Data: x2002
<...>
lpfc 0006:01:00.4: 4:(0):3172 SCSI layer issued Host Reset Data:
<...>--- drivers/scsi/lpfc/lpfc_scsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_scsi.c +1 -1
@@ -3859,7 +3859,7 @@ int lpfc_sli4_scmd_to_wqidx_distr(structuint32_t tag;uint16_t hwq; -if (shost_use_blk_mq (cmnd->device->host)) { +if (cmnd &&shost_use_blk_mq (cmnd->device->host)) { tag =blk_mq_unique_tag (cmnd->request); hwq =blk_mq_unique_tag_to_hwq (tag);
Greg Kroah-Hartman
maintainerPATCH 135/138 rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq()
In reply to a message not in the archive4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alim Akhtar <[email protected]>
commit 70c96dfac0e231424e17743bd52f6cd2ff1f2439 upstream.
As per code flow s3c_rtc_setfreq() will get called with rtc clock disabled and in set_freq we perform h/w registers read/write, which results in a kernel crash on exynos7 platform while probing rtc driver.
Below is code flow:s3c_rtc_probe()
clk_prepare_enable(info->rtc_clk) // rtc clock enabled s3c_rtc_gettime() // will enable clk if not done, and disable it upon exit s3c_rtc_setfreq() //then this will be called with clk disabled
This patch take cares of such issue by adding s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq().
--- drivers/rtc/rtc-s3c.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/rtc/rtc-s3c.c +2 -0
@@ -149,12 +149,14 @@ static int s3c_rtc_setfreq(struct s3c_rtif (!is_power_of_2 (freq))return -EINVAL ; +s3c_rtc_enable_clk (info);spin_lock_irq (&info->pie_lock);if (info->data->set_freq) info->data->set_freq (info, freq);spin_unlock_irq (&info->pie_lock); +s3c_rtc_disable_clk (info);return 0 ; }
Re: [PATCH 4.4 000/138] 4.4.19-stable review
In reply to a message not in the archiveQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.19 release. There are 138 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 Sat Aug 20 13:55:20 UTC 2016. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.19-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Signature · 5 lines
Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America(Silicon Valley) [email protected]
Re: [PATCH 4.4 000/138] 4.4.19-stable review
In reply to a message not in the archiveQuoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.19 release. There are 138 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 Sat Aug 20 13:55:20 UTC 2016. Anything received after that time might be too late.
Build results:
total: 148 pass: 148 fail: 0 Qemu test results: total: 101 pass: 101 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter