* Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries
From: Ross Zwisler @ 2017-05-18 21:29 UTC (permalink / raw)
To: Jan Kara
Cc: Ross Zwisler, Andrew Morton, linux-kernel, Darrick J. Wong,
Alexander Viro, Christoph Hellwig, Dan Williams, Dave Hansen,
Matthew Wilcox, linux-fsdevel, linux-mm, linux-nvdimm,
Kirill A . Shutemov, Pawel Lebioda, Dave Jiang, Xiong Zhou,
Eryu Guan, stable
In-Reply-To: <20170518075037.GA9084@quack2.suse.cz>
On Thu, May 18, 2017 at 09:50:37AM +0200, Jan Kara wrote:
> On Wed 17-05-17 11:16:39, Ross Zwisler wrote:
> > We currently have two related PMD vs PTE races in the DAX code. These can
> > both be easily triggered by having two threads reading and writing
> > simultaneously to the same private mapping, with the key being that private
> > mapping reads can be handled with PMDs but private mapping writes are
> > always handled with PTEs so that we can COW.
> >
> > Here is the first race:
> >
> > CPU 0 CPU 1
> >
> > (private mapping write)
> > __handle_mm_fault()
> > create_huge_pmd() - FALLBACK
> > handle_pte_fault()
> > passes check for pmd_devmap()
> >
> > (private mapping read)
> > __handle_mm_fault()
> > create_huge_pmd()
> > dax_iomap_pmd_fault() inserts PMD
> >
> > dax_iomap_pte_fault() does a PTE fault, but we already have a DAX PMD
> > installed in our page tables at this spot.
> >
> >
> > Here's the second race:
> >
> > CPU 0 CPU 1
> >
> > (private mapping write)
> > __handle_mm_fault()
> > create_huge_pmd() - FALLBACK
> > (private mapping read)
> > __handle_mm_fault()
> > passes check for pmd_none()
> > create_huge_pmd()
> >
> > handle_pte_fault()
> > dax_iomap_pte_fault() inserts PTE
> > dax_iomap_pmd_fault() inserts PMD,
> > but we already have a PTE at
> > this spot.
>
> So I don't see how this second scenario can happen. dax_iomap_pmd_fault()
> will call grab_mapping_entry(). That will either find PTE entry in the
> radix tree -> EEXIST and we retry the fault. Or we will not find PTE entry
> -> try to insert PMD entry which collides with the PTE entry -> EEXIST and
> we retry the fault. Am I missing something?
Yep, sorry, I guess I needed a few extra steps in my flow (the initial private
mapping read by CPU 0):
CPU 0 CPU 1
(private mapping read)
__handle_mm_fault()
passes check for pmd_none()
create_huge_pmd()
dax_iomap_pmd_fault() inserts PMD
(private mapping write)
__handle_mm_fault()
create_huge_pmd() - FALLBACK
(private mapping read)
__handle_mm_fault()
passes check for pmd_none()
create_huge_pmd()
handle_pte_fault()
dax_iomap_pte_fault() inserts PTE
dax_iomap_pmd_fault() inserts PMD,
but we already have a PTE at
this spot.
So what happens is that CPU 0 inserts a DAX PMD into the radix tree that has
real storage backing, and all PTE and PMD faults just use that same PMD radix
tree entry for locking and dirty tracking.
> The first scenario seems to be possible. dax_iomap_pmd_fault() will create
> PMD entry in the radix tree. Then dax_iomap_pte_fault() will come, do
> grab_mapping_entry(), there it sees entry is PMD but we are doing PTE fault
> so I'd think that pmd_downgrade = true... But actually the condition there
> doesn't trigger in this case. And that's a catch that although we asked
> grab_mapping_entry() for PTE, we've got PMD back and that screws us later.
Yep, it was a concious decision when implementing the PMD support to allow one
thread to use PMDs and another to use PTEs in the same range, as long as the
thread faulting in PMDs is the first to insert into the radix tree. A PMD
radix tree entry will be inserted and used for locking and dirty tracking, and
each thread or process can fault in either PTEs or PMDs into its own address
space as needed.
We can revisit this, if you think it is incorrect. The option you outline
below would basically mean that if any thread were to fault in a PTE in a
range, all threads and processes would be forced to use PTEs because we would
use PTEs in the radix tree.
This is cleaner...I'm not sure if the use case of having two threads accessing
the same area, one with PTEs and one with PMDs, is actually prevalent. It's
also maybe a bit weird that the current behavior varies based on which thread
faulted first - if the PTE thread faults first, it'll insert a PTE into the
radix tree and everyone will just use PTEs.
> Actually I'm not convinced your patch quite fixes this because
> dax_load_hole() or dax_insert_mapping_entry() will modify the passed entry
> with the assumption that it's PTE entry and so they will likely corrupt the
> entry in the radix tree.
I don't think we can ever call dax_load_hole() if we have a DAX PMD entry in
the radix tree, because we have a block mapping from the filesystem.
For dax_insert_mapping_entry(), we do the right thing. From the comments
above the function:
* If we happen to be trying to insert a PTE and there is a PMD
* already in the tree, we will skip the insertion and just dirty the PMD as
* appropriate. If we happen to be trying to insert a PTE and there is a PMD
* already in the tree, we will skip the insertion and just dirty the PMD as
* appropriate.
> So I think to fix the first case we should rather modify
> grab_mapping_entry() to properly go through the pmd_downgrade path once we
> find PMD entry and we do PTE fault.
>
> What do you think?
That could also work, though I do think the fix as submitted is correct.
I think it comes down to whether we want to keep the behavior where a thread
faulting in a PTEs will use an existing PMD entry in the radix tree, instead
of making all other threads fall back to PTEs.
I think either way solves this issue for the DAX case...but do you understand
how this is solved for other fault handlers? They don't have any isolation
between faults either in the mm/memory.c code, and are susceptible to the same
races. How do they deal with the fact that by the time they get to their PTE
fault handler, a racing PMD fault handler in another thread could have
inserted a PMD into their page tables, and vice versa?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3] KVM: x86: Fix potential preemption when get the current kvmclock timestamp
From: Wanpeng Li @ 2017-05-18 21:53 UTC (permalink / raw)
To: Paolo Bonzini
Cc: linux-kernel@vger.kernel.org, kvm, Radim Krčmář,
Wanpeng Li, stable
In-Reply-To: <ca85b1b3-5d0e-bd26-c235-49fda66b0be2@redhat.com>
Ping,
2017-05-12 15:44 GMT+08:00 Paolo Bonzini <pbonzini@redhat.com>:
>
>
> On 12/05/2017 03:12, Wanpeng Li wrote:
>> From: Wanpeng Li <wanpeng.li@hotmail.com>
>>
>> BUG: using __this_cpu_read() in preemptible [00000000] code: qemu-system-x86/2809
>> caller is __this_cpu_preempt_check+0x13/0x20
>> CPU: 2 PID: 2809 Comm: qemu-system-x86 Not tainted 4.11.0+ #13
>> Call Trace:
>> dump_stack+0x99/0xce
>> check_preemption_disabled+0xf5/0x100
>> __this_cpu_preempt_check+0x13/0x20
>> get_kvmclock_ns+0x6f/0x110 [kvm]
>> get_time_ref_counter+0x5d/0x80 [kvm]
>> kvm_hv_process_stimers+0x2a1/0x8a0 [kvm]
>> ? kvm_hv_process_stimers+0x2a1/0x8a0 [kvm]
>> ? kvm_arch_vcpu_ioctl_run+0xac9/0x1ce0 [kvm]
>> kvm_arch_vcpu_ioctl_run+0x5bf/0x1ce0 [kvm]
>> kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
>> ? kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
>> ? __fget+0xf3/0x210
>> do_vfs_ioctl+0xa4/0x700
>> ? __fget+0x114/0x210
>> SyS_ioctl+0x79/0x90
>> entry_SYSCALL_64_fastpath+0x23/0xc2
>> RIP: 0033:0x7f9d164ed357
>> ? __this_cpu_preempt_check+0x13/0x20
>>
>> This can be reproduced by run kvm-unit-tests/hyperv_stimer.flat w/
>> CONFIG_PREEMPT and CONFIG_DEBUG_PREEMPT enabled.
>>
>> Safe access to per-CPU data requires a couple of constraints, though: the
>> thread working with the data cannot be preempted and it cannot be migrated
>> while it manipulates per-CPU variables. If the thread is preempted, the
>> thread that replaces it could try to work with the same variables; migration
>> to another CPU could also cause confusion. However there is no preemption
>> disable when reads host per-CPU tsc rate to calculate the current kvmclock
>> timestamp.
>>
>> This patch fixes it by utilizing get_cpu/put_cpu pair to guarantee both
>> __this_cpu_read() and rdtsc() are not preempted.
>>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: Radim Krčmář <rkrcmar@redhat.com>
>> Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
>> ---
>> v2 -> v3:
>> * update patch description
>> v1 -> v2:
>> * utilize get_cpu/put_cpu pair to protect both __this_cpu_read and rdtsc()
>>
>> arch/x86/kvm/x86.c | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index b54125b..3b5fc7e 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -1763,6 +1763,7 @@ u64 get_kvmclock_ns(struct kvm *kvm)
>> {
>> struct kvm_arch *ka = &kvm->arch;
>> struct pvclock_vcpu_time_info hv_clock;
>> + u64 ret;
>>
>> spin_lock(&ka->pvclock_gtod_sync_lock);
>> if (!ka->use_master_clock) {
>> @@ -1774,10 +1775,17 @@ u64 get_kvmclock_ns(struct kvm *kvm)
>> hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset;
>> spin_unlock(&ka->pvclock_gtod_sync_lock);
>>
>> + /* both __this_cpu_read() and rdtsc() should be on the same cpu */
>> + get_cpu();
>> +
>> kvm_get_time_scale(NSEC_PER_SEC, __this_cpu_read(cpu_tsc_khz) * 1000LL,
>> &hv_clock.tsc_shift,
>> &hv_clock.tsc_to_system_mul);
>> - return __pvclock_read_cycles(&hv_clock, rdtsc());
>> + ret = __pvclock_read_cycles(&hv_clock, rdtsc());
>> +
>> + put_cpu();
>> +
>> + return ret;
>> }
>>
>> static void kvm_setup_pvclock_page(struct kvm_vcpu *v)
>>
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Cc: stable@vger.kernel.org
^ permalink raw reply
* [PATCH v2] vmbus: fix missed ring events on boot
From: Stephen Hemminger @ 2017-05-18 22:25 UTC (permalink / raw)
To: kys; +Cc: devel, stable, Stephen Hemminger
During initialization, the channel initialization code schedules the
tasklet to scan the VMBUS receive event page (i.e. simulates an
interrupt). The problem was that it invokes the tasklet on a different
CPU from where it normally runs and therefore if an event is present,
it will clear the bit but not find the associated channel.
This can lead to missed events, typically stuck tasks, during bootup
when sub channels are being initialized. Typically seen as stuck
boot with 8 or more CPU's.
This patch is not necessary for upstream (4.11 and later) since
commit 631e63a9f346 ("vmbus: change to per channel tasklet").
This changed vmbus code to get rid of common tasklet which
caused the problem.
Cc: stable@vger.kernel.org
Fixes: 638fea33aee8 ("Drivers: hv: vmbus: fix the race when querying & updating the percpu list")
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
v2 - fix generic in hv_event_tasklet_enable
drivers/hv/channel_mgmt.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index a58cd102af1b..51be9ec8a51b 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -361,8 +361,17 @@ void hv_event_tasklet_enable(struct vmbus_channel *channel)
tasklet = hv_context.event_dpc[channel->target_cpu];
tasklet_enable(tasklet);
- /* In case there is any pending event */
- tasklet_schedule(tasklet);
+ /*
+ * In case there is any pending event schedule a rescan
+ * but must be on the correct CPU for the channel.
+ */
+ if (channel->target_cpu == get_cpu())
+ tasklet_schedule(tasklet);
+ else
+ smp_call_function_single(channel->target_cpu,
+ (smp_call_func_t)tasklet_schedule,
+ tasklet, false);
+ put_cpu();
}
void hv_process_channel_removal(struct vmbus_channel *channel, u32 relid)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] usb: gadget: f_mass_storage: Serialize wake and sleep execution
From: Thinh Nguyen @ 2017-05-18 22:26 UTC (permalink / raw)
To: Felipe Balbi
Cc: linux-usb@vger.kernel.org, Philipp Gesang, Ingo Molnar, John Youn,
Alan Stern, stable@vger.kernel.org
In-Reply-To: <a69a607e9b92156f97d4ba5e2a6c4177eeb2aea7.1494546251.git.thinhn@synopsys.com>
Hi Felipe,
On 5/11/2017 5:27 PM, Thinh Nguyen wrote:
> f_mass_storage has a memorry barrier issue with the sleep and wake
> functions that can cause a deadlock. This results in intermittent hangs
> during MSC file transfer. The host will reset the device after receiving
> no response to resume the transfer. This issue is seen when dwc3 is
> processing 2 transfer-in-progress events at the same time, invoking
> completion handlers for CSW and CBW. Also this issue occurs depending on
> the system timing and latency.
>
> To increase the chance to hit this issue, you can force dwc3 driver to
> wait and process those 2 events at once by adding a small delay (~100us)
> in dwc3_check_event_buf() whenever the request is for CSW and read the
> event count again. Avoid debugging with printk and ftrace as extra
> delays and memory barrier will mask this issue.
>
> Scenario which can lead to failure:
> -----------------------------------
> 1) The main thread sleeps and waits for the next command in
> get_next_command().
> 2) bulk_in_complete() wakes up main thread for CSW.
> 3) bulk_out_complete() tries to wake up the running main thread for CBW.
> 4) thread_wakeup_needed is not loaded with correct value in
> sleep_thread().
> 5) Main thread goes to sleep again.
>
> The pattern is shown below. Note the 2 critical variables.
> * common->thread_wakeup_needed
> * bh->state
>
> CPU 0 (sleep_thread) CPU 1 (wakeup_thread)
> ============================== ===============================
>
> bh->state = BH_STATE_FULL;
> smp_wmb();
> thread_wakeup_needed = 0; thread_wakeup_needed = 1;
> smp_rmb();
> if (bh->state != BH_STATE_FULL)
> sleep again ...
>
> As pointed out by Alan Stern, this is an R-pattern issue. The issue can
> be seen when there are two wakeups in quick succession. The
> thread_wakeup_needed can be overwritten in sleep_thread, and the read of
> the bh->state maybe reordered before the write to thread_wakeup_needed.
>
> This patch applies full memory barrier smp_mb() in both sleep_thread()
> and wakeup_thread() to ensure the order which the thread_wakeup_needed
> and bh->state are written and loaded.
>
> However, a better solution in the future would be to use wait_queue
> method that takes care of managing memory barrier between waker and
> waiter.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
> ---
Will this patch go on the rc?
Thanks,
Thinh
^ permalink raw reply
* [PATCH v2] scsi: zero per-cmd private driver data for each MQ I/O
From: Long Li @ 2017-05-18 22:40 UTC (permalink / raw)
To: James E.J. Bottomley, Martin K. Petersen, linux-scsi,
linux-kernel, KY Srinivasan, Bart Van Assche, Christoph Hellwig,
Stephen Hemminger
Cc: Long Li, stable
From: Long Li <longli@microsoft.com>
In lower layer driver's (LLD) scsi_host_template, the driver may optionally
ask SCSI to allocate its private driver memory for each command, by
specifying cmd_size. This memory is allocated at the end of scsi_cmnd by SCSI.
Later when SCSI queues a command, the LLD can use scsi_cmd_priv to get to its
private data.
Some LLD, e.g. hv_storvsc, doesn't clear its private data before use. In
this case, the LLD may get to stale or uninitialized data in its private
driver memory. This may result in unexpected driver and hardware behavior.
Fix this problem by also zeroing the private driver memory before passing
them to LLD.
Signed-off-by: Long Li <longli@microsoft.com>
Reviewed-by: Bart Van Assche <Bart.VanAssche@sandisk.com>
Reviewed-by: KY Srinivasan <kys@microsoft.com>
Reviewed-by: Christoph Hellwig <hch@infradead.org>
CC: stable@vger.kernel.org
---
drivers/scsi/scsi_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 19125d7..a821593 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1850,7 +1850,7 @@ static int scsi_mq_prep_fn(struct request *req)
/* zero out the cmd, except for the embedded scsi_request */
memset((char *)cmd + sizeof(cmd->req), 0,
- sizeof(*cmd) - sizeof(cmd->req));
+ sizeof(*cmd) - sizeof(cmd->req) + shost->hostt->cmd_size);
req->special = cmd;
--
2.7.4
^ permalink raw reply related
* Re: FAILED: patch "[PATCH] dax: fix data corruption when fault races with write" failed to apply to 4.11-stable tree
From: Ross Zwisler @ 2017-05-18 23:14 UTC (permalink / raw)
To: gregkh; +Cc: jack, akpm, dan.j.williams, ross.zwisler, stable, torvalds
In-Reply-To: <149509236415978@kroah.com>
On Thu, May 18, 2017 at 09:26:04AM +0200, gregkh@linuxfoundation.org wrote:
>
> The patch below does not apply to the 4.11-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
>
> thanks,
>
> greg k-h
The following patch from Jan was sent in v3 of his series before he had merged
with my tracepoint changes, and applies cleanly to v4.11.1. This is for the
following upstream commit:
commit 13e451fdc1af ("dax: fix data corruption when fault races with write")
--- >8 ---
>From d23bb209e613befbf568c54298bb3add847653a0 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Tue, 9 May 2017 14:18:37 +0200
Subject: [PATCH] dax: Fix data corruption when fault races with write
Currently DAX read fault can race with write(2) in the following way:
CPU1 - write(2) CPU2 - read fault
dax_iomap_pte_fault()
->iomap_begin() - sees hole
dax_iomap_rw()
iomap_apply()
->iomap_begin - allocates blocks
dax_iomap_actor()
invalidate_inode_pages2_range()
- there's nothing to invalidate
grab_mapping_entry()
- we add zero page in the radix tree
and map it to page tables
The result is that hole page is mapped into page tables (and thus zeros
are seen in mmap) while file has data written in that place.
Fix the problem by locking exception entry before mapping blocks for the
fault. That way we are sure invalidate_inode_pages2_range() call for
racing write will either block on entry lock waiting for the fault to
finish (and unmap stale page tables after that) or read fault will see
already allocated blocks by write(2).
Fixes: 9f141d6ef6258a3a37a045842d9ba7e68f368956
CC: stable@vger.kernel.org
Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
---
fs/dax.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 85abd74..d1d2cd9 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1153,23 +1153,23 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
if ((vmf->flags & FAULT_FLAG_WRITE) && !vmf->cow_page)
flags |= IOMAP_WRITE;
+ entry = grab_mapping_entry(mapping, vmf->pgoff, 0);
+ if (IS_ERR(entry))
+ return dax_fault_return(PTR_ERR(entry));
+
/*
* Note that we don't bother to use iomap_apply here: DAX required
* the file system block size to be equal the page size, which means
* that we never have to deal with more than a single extent here.
*/
error = ops->iomap_begin(inode, pos, PAGE_SIZE, flags, &iomap);
- if (error)
- return dax_fault_return(error);
- if (WARN_ON_ONCE(iomap.offset + iomap.length < pos + PAGE_SIZE)) {
- vmf_ret = dax_fault_return(-EIO); /* fs corruption? */
- goto finish_iomap;
+ if (error) {
+ vmf_ret = dax_fault_return(error);
+ goto unlock_entry;
}
-
- entry = grab_mapping_entry(mapping, vmf->pgoff, 0);
- if (IS_ERR(entry)) {
- vmf_ret = dax_fault_return(PTR_ERR(entry));
- goto finish_iomap;
+ if (WARN_ON_ONCE(iomap.offset + iomap.length < pos + PAGE_SIZE)) {
+ error = -EIO; /* fs corruption? */
+ goto error_finish_iomap;
}
sector = dax_iomap_sector(&iomap, pos);
@@ -1191,13 +1191,13 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
}
if (error)
- goto error_unlock_entry;
+ goto error_finish_iomap;
__SetPageUptodate(vmf->cow_page);
vmf_ret = finish_fault(vmf);
if (!vmf_ret)
vmf_ret = VM_FAULT_DONE_COW;
- goto unlock_entry;
+ goto finish_iomap;
}
switch (iomap.type) {
@@ -1217,7 +1217,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
case IOMAP_HOLE:
if (!(vmf->flags & FAULT_FLAG_WRITE)) {
vmf_ret = dax_load_hole(mapping, &entry, vmf);
- goto unlock_entry;
+ goto finish_iomap;
}
/*FALLTHRU*/
default:
@@ -1226,10 +1226,8 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
break;
}
- error_unlock_entry:
+ error_finish_iomap:
vmf_ret = dax_fault_return(error) | major;
- unlock_entry:
- put_locked_mapping_entry(mapping, vmf->pgoff, entry);
finish_iomap:
if (ops->iomap_end) {
int copied = PAGE_SIZE;
@@ -1244,6 +1242,8 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
*/
ops->iomap_end(inode, pos, PAGE_SIZE, copied, flags, &iomap);
}
+ unlock_entry:
+ put_locked_mapping_entry(mapping, vmf->pgoff, entry);
return vmf_ret;
}
--
2.9.4
^ permalink raw reply related
* Re: FAILED: patch "[PATCH] dax: fix data corruption when fault races with write" failed to apply to 4.10-stable tree
From: Ross Zwisler @ 2017-05-18 23:20 UTC (permalink / raw)
To: gregkh; +Cc: jack, akpm, dan.j.williams, ross.zwisler, stable, torvalds
In-Reply-To: <1495092368153166@kroah.com>
On Thu, May 18, 2017 at 09:26:08AM +0200, gregkh@linuxfoundation.org wrote:
>
> The patch below does not apply to the 4.10-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
>
> thanks,
>
> greg k-h
The following patch from Jan was sent in v3 of his series before he had merged
with my tracepoint changes, and applies cleanly to v4.10.6. This is for the
following upstream commit:
commit 13e451fdc1af ("dax: fix data corruption when fault races with write")
This patch relies on the previous patch in the series to work correctly, so
you'll need to wait for Jan to backport that before applying this one. Here's
the commit you need from Jan:
commit fb26a1cbed8c ("ext4: return to starting transaction in ext4_dax_huge_fault()")
I'll send you a backport for patch 5 in that series tomorrow, a backport of
this commit:
commit 876f29460cbd ("dax: fix PMD data corruption when fault races with write")
Obviously no need to wait for that one before applying this one. :)
--- >8 ---
>From a9336fe67e892da2fc167e60db6d6069b0a786b1 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Tue, 9 May 2017 14:18:37 +0200
Subject: [PATCH] dax: Fix data corruption when fault races with write
Currently DAX read fault can race with write(2) in the following way:
CPU1 - write(2) CPU2 - read fault
dax_iomap_pte_fault()
->iomap_begin() - sees hole
dax_iomap_rw()
iomap_apply()
->iomap_begin - allocates blocks
dax_iomap_actor()
invalidate_inode_pages2_range()
- there's nothing to invalidate
grab_mapping_entry()
- we add zero page in the radix tree
and map it to page tables
The result is that hole page is mapped into page tables (and thus zeros
are seen in mmap) while file has data written in that place.
Fix the problem by locking exception entry before mapping blocks for the
fault. That way we are sure invalidate_inode_pages2_range() call for
racing write will either block on entry lock waiting for the fault to
finish (and unmap stale page tables after that) or read fault will see
already allocated blocks by write(2).
Fixes: 9f141d6ef6258a3a37a045842d9ba7e68f368956
CC: stable@vger.kernel.org
Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
---
fs/dax.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index a39b404..4bffc4a 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1156,23 +1156,23 @@ int dax_iomap_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
if ((vmf->flags & FAULT_FLAG_WRITE) && !vmf->cow_page)
flags |= IOMAP_WRITE;
+ entry = grab_mapping_entry(mapping, vmf->pgoff, 0);
+ if (IS_ERR(entry))
+ return dax_fault_return(PTR_ERR(entry));
+
/*
* Note that we don't bother to use iomap_apply here: DAX required
* the file system block size to be equal the page size, which means
* that we never have to deal with more than a single extent here.
*/
error = ops->iomap_begin(inode, pos, PAGE_SIZE, flags, &iomap);
- if (error)
- return dax_fault_return(error);
- if (WARN_ON_ONCE(iomap.offset + iomap.length < pos + PAGE_SIZE)) {
- vmf_ret = dax_fault_return(-EIO); /* fs corruption? */
- goto finish_iomap;
+ if (error) {
+ vmf_ret = dax_fault_return(error);
+ goto unlock_entry;
}
-
- entry = grab_mapping_entry(mapping, vmf->pgoff, 0);
- if (IS_ERR(entry)) {
- vmf_ret = dax_fault_return(PTR_ERR(entry));
- goto finish_iomap;
+ if (WARN_ON_ONCE(iomap.offset + iomap.length < pos + PAGE_SIZE)) {
+ error = -EIO; /* fs corruption? */
+ goto error_finish_iomap;
}
sector = dax_iomap_sector(&iomap, pos);
@@ -1194,13 +1194,13 @@ int dax_iomap_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
}
if (error)
- goto error_unlock_entry;
+ goto error_finish_iomap;
__SetPageUptodate(vmf->cow_page);
vmf_ret = finish_fault(vmf);
if (!vmf_ret)
vmf_ret = VM_FAULT_DONE_COW;
- goto unlock_entry;
+ goto finish_iomap;
}
switch (iomap.type) {
@@ -1220,7 +1220,7 @@ int dax_iomap_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
case IOMAP_HOLE:
if (!(vmf->flags & FAULT_FLAG_WRITE)) {
vmf_ret = dax_load_hole(mapping, &entry, vmf);
- goto unlock_entry;
+ goto finish_iomap;
}
/*FALLTHRU*/
default:
@@ -1229,10 +1229,8 @@ int dax_iomap_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
break;
}
- error_unlock_entry:
+ error_finish_iomap:
vmf_ret = dax_fault_return(error) | major;
- unlock_entry:
- put_locked_mapping_entry(mapping, vmf->pgoff, entry);
finish_iomap:
if (ops->iomap_end) {
int copied = PAGE_SIZE;
@@ -1247,6 +1245,8 @@ int dax_iomap_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
*/
ops->iomap_end(inode, pos, PAGE_SIZE, copied, flags, &iomap);
}
+ unlock_entry:
+ put_locked_mapping_entry(mapping, vmf->pgoff, entry);
return vmf_ret;
}
EXPORT_SYMBOL_GPL(dax_iomap_fault);
--
2.9.4
^ permalink raw reply related
* Re: [PATCH 1/3] btrfs: fix race with relocation recovery and fs_root setup
From: Liu Bo @ 2017-05-18 23:58 UTC (permalink / raw)
To: jeffm; +Cc: linux-btrfs, stable
In-Reply-To: <1495035516-3217-1-git-send-email-jeffm@suse.com>
On Wed, May 17, 2017 at 11:38:34AM -0400, jeffm@suse.com wrote:
> From: Jeff Mahoney <jeffm@suse.com>
>
> If we have to recover relocation during mount, we'll ultimately have to
> evict the orphan inode. That goes through the reservation dance, where
> priority_reclaim_metadata_space and flush_space expect fs_info->fs_root
> to be valid. That's the next thing to be set up during mount, so we
> crash, almost always in flush_space trying to join the transaction
> but priority_reclaim_metadata_space is possible as well. This call
> path has been problematic in the past WRT whether ->fs_root is valid
> yet. Commit 957780eb278 (Btrfs: introduce ticketed enospc
> infrastructure) added new users that are called in the direct path
> instead of the async path that had already been worked around.
>
> The thing is that we don't actually need the fs_root, specifically, for
> anything. We either use it to determine whether the root is the
> chunk_root for use in choosing an allocation profile or as a root to pass
> btrfs_join_transaction before immediately committing it. Anything that
> isn't the chunk root works in the former case and any root works in
> the latter.
>
> A simple fix is to use a root we know will always be there: the
> extent_root.
>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Thanks,
-liubo
> Cc: <stable@vger.kernel.org> # v4.8+
> Fixes: 957780eb278 (Btrfs: introduce ticketed enospc infrastructure)
> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
> ---
> fs/btrfs/extent-tree.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index be54776..9894c4e 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -4834,7 +4834,7 @@ static int may_commit_transaction(struct btrfs_fs_info *fs_info,
> spin_unlock(&delayed_rsv->lock);
>
> commit:
> - trans = btrfs_join_transaction(fs_info->fs_root);
> + trans = btrfs_join_transaction(fs_info->extent_root);
> if (IS_ERR(trans))
> return -ENOSPC;
>
> @@ -4852,7 +4852,7 @@ static int flush_space(struct btrfs_fs_info *fs_info,
> struct btrfs_space_info *space_info, u64 num_bytes,
> u64 orig_bytes, int state)
> {
> - struct btrfs_root *root = fs_info->fs_root;
> + struct btrfs_root *root = fs_info->extent_root;
> struct btrfs_trans_handle *trans;
> int nr;
> int ret = 0;
> @@ -5052,7 +5052,7 @@ static void priority_reclaim_metadata_space(struct btrfs_fs_info *fs_info,
> int flush_state = FLUSH_DELAYED_ITEMS_NR;
>
> spin_lock(&space_info->lock);
> - to_reclaim = btrfs_calc_reclaim_metadata_size(fs_info->fs_root,
> + to_reclaim = btrfs_calc_reclaim_metadata_size(fs_info->extent_root,
> space_info);
> if (!to_reclaim) {
> spin_unlock(&space_info->lock);
> --
> 1.8.5.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] btrfs: fix memory leak in update_space_info failure path
From: Liu Bo @ 2017-05-19 0:20 UTC (permalink / raw)
To: jeffm; +Cc: linux-btrfs, # v3 . 14+
In-Reply-To: <20170517134937.30774-1-jeffm@suse.com>
On Wed, May 17, 2017 at 09:49:37AM -0400, jeffm@suse.com wrote:
> From: Jeff Mahoney <jeffm@suse.com>
>
> If we fail to add the space_info kobject, we'll leak the memory
> for the percpu counter.
>
> Fixes: 6ab0a2029c (btrfs: publish allocation data in sysfs)
> Cc: <stable@vger.kernel.org> # v3.14+
> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Looks good.
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Thanks,
-liubo
^ permalink raw reply
* [for-next][PATCH 2/8] tracing/kprobes: Enforce kprobes teardown after testing
From: Steven Rostedt @ 2017-05-19 0:43 UTC (permalink / raw)
To: linux-kernel
Cc: Ingo Molnar, Andrew Morton, Thomas Gleixner, Masami Hiramatsu,
stable
In-Reply-To: <20170519004313.407366856@goodmis.org>
[-- Attachment #1: 0002-tracing-kprobes-Enforce-kprobes-teardown-after-testi.patch --]
[-- Type: text/plain, Size: 2833 bytes --]
From: Thomas Gleixner <tglx@linutronix.de>
Enabling the tracer selftest triggers occasionally the warning in
text_poke(), which warns when the to be modified page is not marked
reserved.
The reason is that the tracer selftest installs kprobes on functions marked
__init for testing. These probes are removed after the tests, but that
removal schedules the delayed kprobes_optimizer work, which will do the
actual text poke. If the work is executed after the init text is freed,
then the warning triggers. The bug can be reproduced reliably when the work
delay is increased.
Flush the optimizer work and wait for the optimizing/unoptimizing lists to
become empty before returning from the kprobes tracer selftest. That
ensures that all operations which were queued due to the probes removal
have completed.
Link: http://lkml.kernel.org/r/20170516094802.76a468bb@gandalf.local.home
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: stable@vger.kernel.org
Fixes: 6274de498 ("kprobes: Support delayed unoptimizing")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
include/linux/kprobes.h | 3 +++
kernel/kprobes.c | 2 +-
kernel/trace/trace_kprobe.c | 5 +++++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index 30f90c1a0aaf..541df0b5b815 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -349,6 +349,9 @@ extern int proc_kprobes_optimization_handler(struct ctl_table *table,
int write, void __user *buffer,
size_t *length, loff_t *ppos);
#endif
+extern void wait_for_kprobe_optimizer(void);
+#else
+static inline void wait_for_kprobe_optimizer(void) { }
#endif /* CONFIG_OPTPROBES */
#ifdef CONFIG_KPROBES_ON_FTRACE
extern void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 7367e0ec6f81..199243bba554 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -595,7 +595,7 @@ static void kprobe_optimizer(struct work_struct *work)
}
/* Wait for completing optimization and unoptimization */
-static void wait_for_kprobe_optimizer(void)
+void wait_for_kprobe_optimizer(void)
{
mutex_lock(&kprobe_mutex);
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 8485f6738a87..c129fca6ec99 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1535,6 +1535,11 @@ static __init int kprobe_trace_self_tests_init(void)
end:
release_all_trace_kprobes();
+ /*
+ * Wait for the optimizer work to finish. Otherwise it might fiddle
+ * with probes in already freed __init text.
+ */
+ wait_for_kprobe_optimizer();
if (warn)
pr_cont("NG: Some tests are failed. Please check them.\n");
else
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 3.18 00/49] 3.18.54-stable review
From: Guenter Roeck @ 2017-05-19 1:04 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <20170518131643.028057293@linuxfoundation.org>
On 05/18/2017 06:16 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.54 release.
> There are 49 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 May 20 13:16:30 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 136 pass: 136 fail: 0
Qemu test results:
total: 111 pass: 111 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply
* Re: [PATCH 4.11 000/114] 4.11.2-stable review
From: Guenter Roeck @ 2017-05-19 1:10 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <20170518103604.736737251@linuxfoundation.org>
On 05/18/2017 03:45 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.11.2 release.
> There are 114 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 May 20 10:35:20 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply
* Re: [PATCH 4.4 00/56] 4.4.69-stable review
From: Guenter Roeck @ 2017-05-19 1:10 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <20170518104840.395932131@linuxfoundation.org>
On 05/18/2017 03:48 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.69 release.
> There are 56 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 May 20 10:48:24 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 115 pass: 115 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply
* Re: [PATCH 4.10 00/93] 4.10.17-stable review
From: Guenter Roeck @ 2017-05-19 1:10 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <20170518104743.163522815@linuxfoundation.org>
On 05/18/2017 03:46 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.10.17 release.
> There are 93 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 May 20 10:47:19 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply
* Re: [PATCH 4.9 00/80] 4.9.29-stable review
From: Guenter Roeck @ 2017-05-19 1:10 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <20170518104833.667298773@linuxfoundation.org>
On 05/18/2017 03:47 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.29 release.
> There are 80 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 May 20 10:48:15 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply
* Re: [PATCH v2] scsi: zero per-cmd private driver data for each MQ I/O
From: Martin K. Petersen @ 2017-05-19 1:45 UTC (permalink / raw)
To: Long Li
Cc: James E.J. Bottomley, Martin K. Petersen, linux-scsi,
linux-kernel, KY Srinivasan, Bart Van Assche, Christoph Hellwig,
Stephen Hemminger, Long Li, stable
In-Reply-To: <1495147205-28778-1-git-send-email-longli@exchange.microsoft.com>
Long,
> In lower layer driver's (LLD) scsi_host_template, the driver may
> optionally ask SCSI to allocate its private driver memory for each
> command, by specifying cmd_size. This memory is allocated at the end
> of scsi_cmnd by SCSI. Later when SCSI queues a command, the LLD can
> use scsi_cmd_priv to get to its private data.
>
> Some LLD, e.g. hv_storvsc, doesn't clear its private data before
> use. In this case, the LLD may get to stale or uninitialized data in
> its private driver memory. This may result in unexpected driver and
> hardware behavior.
>
> Fix this problem by also zeroing the private driver memory before
> passing them to LLD.
Applied to 4.12/scsi-fixes. Thank you!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH v2 2/2] dmaengine: ep93xx: Don't drain the transfers in terminate_all()
From: Vinod Koul @ 2017-05-19 3:55 UTC (permalink / raw)
To: Alexander Sverdlin; +Cc: dmaengine, Dan Williams, stable
In-Reply-To: <20170517173354.20695-3-alexander.sverdlin@gmail.com>
On Wed, May 17, 2017 at 07:33:54PM +0200, Alexander Sverdlin wrote:
> /**
> + * ep93xx_dma_synchronize - Synchronizes the termination of transfers to the
> + * current context.
> + * @chan: channel
> + *
> + * Synchronizes the DMA channel termination to the current context. When this
> + * function returns it is guaranteed that all transfers for previously issued
> + * descriptors have stopped and and it is safe to free the memory assoicated
s/assoicated/associated
--
~Vinod
^ permalink raw reply
* Re: [PATCH 4.11 000/114] 4.11.2-stable review
From: Greg Kroah-Hartman @ 2017-05-19 5:37 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <1f86185e-b943-a687-707a-41dcdc4ac729@roeck-us.net>
On Thu, May 18, 2017 at 06:10:07PM -0700, Guenter Roeck wrote:
> On 05/18/2017 03:45 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.11.2 release.
> > There are 114 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 May 20 10:35:20 UTC 2017.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 145 pass: 145 fail: 0
> Qemu test results:
> total: 122 pass: 122 fail: 0
>
> Details are available at http://kerneltests.org/builders.
Great, thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply
* patch "usb: serial: option: add Telit ME910 support" added to usb-linus
From: gregkh @ 2017-05-19 8:11 UTC (permalink / raw)
To: dnlplm, johan, stable
This is a note to let you know that I've just added the patch titled
usb: serial: option: add Telit ME910 support
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 40dd46048c155b8f0683f468c950a1c107f77a7c Mon Sep 17 00:00:00 2001
From: Daniele Palmas <dnlplm@gmail.com>
Date: Wed, 3 May 2017 10:28:54 +0200
Subject: usb: serial: option: add Telit ME910 support
This patch adds support for Telit ME910 PID 0x1100.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/usb/serial/option.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index af67a0de6b5d..3bf61acfc26b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -281,6 +281,7 @@ static void option_instat_callback(struct urb *urb);
#define TELIT_PRODUCT_LE922_USBCFG0 0x1042
#define TELIT_PRODUCT_LE922_USBCFG3 0x1043
#define TELIT_PRODUCT_LE922_USBCFG5 0x1045
+#define TELIT_PRODUCT_ME910 0x1100
#define TELIT_PRODUCT_LE920 0x1200
#define TELIT_PRODUCT_LE910 0x1201
#define TELIT_PRODUCT_LE910_USBCFG4 0x1206
@@ -640,6 +641,11 @@ static const struct option_blacklist_info simcom_sim7100e_blacklist = {
.reserved = BIT(5) | BIT(6),
};
+static const struct option_blacklist_info telit_me910_blacklist = {
+ .sendsetup = BIT(0),
+ .reserved = BIT(1) | BIT(3),
+};
+
static const struct option_blacklist_info telit_le910_blacklist = {
.sendsetup = BIT(0),
.reserved = BIT(1) | BIT(2),
@@ -1235,6 +1241,8 @@ static const struct usb_device_id option_ids[] = {
.driver_info = (kernel_ulong_t)&telit_le922_blacklist_usbcfg3 },
{ USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG5, 0xff),
.driver_info = (kernel_ulong_t)&telit_le922_blacklist_usbcfg0 },
+ { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910),
+ .driver_info = (kernel_ulong_t)&telit_me910_blacklist },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910),
.driver_info = (kernel_ulong_t)&telit_le910_blacklist },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910_USBCFG4),
--
2.13.0
^ permalink raw reply related
* patch "USB: serial: ftdi_sio: fix setting latency for unprivileged users" added to usb-linus
From: gregkh @ 2017-05-19 8:11 UTC (permalink / raw)
To: anthony.mallet, johan, stable
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: fix setting latency for unprivileged users
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From bb246681b3ed0967489a7401ad528c1aaa1a4c2e Mon Sep 17 00:00:00 2001
From: Anthony Mallet <anthony.mallet@laas.fr>
Date: Fri, 5 May 2017 17:30:16 +0200
Subject: USB: serial: ftdi_sio: fix setting latency for unprivileged users
Commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
flag") enables unprivileged users to set the FTDI latency timer,
but there was a logic flaw that skipped sending the corresponding
USB control message to the device.
Specifically, the device latency timer would not be updated until next
open, something which was later also inadvertently broken by commit
c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port
probe").
A recent commit c6dce2626606 ("USB: serial: ftdi_sio: fix extreme
low-latency setting") disabled the low-latency mode by default so we now
need this fix to allow unprivileged users to again enable it.
Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr>
[johan: amend commit message]
Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
Fixes: c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port probe").
Cc: stable <stable@vger.kernel.org> # 2.6.31
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/usb/serial/ftdi_sio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index d38780fa8788..0e634c11abbf 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1527,9 +1527,9 @@ static int set_serial_info(struct tty_struct *tty,
(new_serial.flags & ASYNC_FLAGS));
priv->custom_divisor = new_serial.custom_divisor;
+check_and_exit:
write_latency_timer(port);
-check_and_exit:
if ((old_priv.flags & ASYNC_SPD_MASK) !=
(priv->flags & ASYNC_SPD_MASK)) {
if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
--
2.13.0
^ permalink raw reply related
* patch "USB: serial: io_ti: fix div-by-zero in set_termios" added to usb-linus
From: gregkh @ 2017-05-19 8:11 UTC (permalink / raw)
To: johan, gregkh, stable
This is a note to let you know that I've just added the patch titled
USB: serial: io_ti: fix div-by-zero in set_termios
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 6aeb75e6adfaed16e58780309613a578fe1ee90b Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Thu, 11 May 2017 11:41:21 +0200
Subject: USB: serial: io_ti: fix div-by-zero in set_termios
Fix a division-by-zero in set_termios when debugging is enabled and a
high-enough speed has been requested so that the divisor value becomes
zero.
Instead of just fixing the offending debug statement, cap the baud rate
at the base as a zero divisor value also appears to crash the firmware.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org> # 2.6.12
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/usb/serial/io_ti.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index 87798e625d6c..6cefb9cb133d 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -2336,8 +2336,11 @@ static void change_port_settings(struct tty_struct *tty,
if (!baud) {
/* pick a default, any default... */
baud = 9600;
- } else
+ } else {
+ /* Avoid a zero divisor. */
+ baud = min(baud, 461550);
tty_encode_baud_rate(tty, baud, baud);
+ }
edge_port->baud_rate = baud;
config->wBaudRate = (__u16)((461550L + baud/2) / baud);
--
2.13.0
^ permalink raw reply related
* patch "USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs" added to usb-linus
From: gregkh @ 2017-05-19 8:11 UTC (permalink / raw)
To: andrey, johan, stable
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 5f63424ab7daac840df2b12dd5bcc5b38d50f779 Mon Sep 17 00:00:00 2001
From: Andrey Korolyov <andrey@xdel.ru>
Date: Tue, 16 May 2017 23:54:41 +0300
Subject: USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
This patch adds support for recognition of ARM-USB-TINY(H) devices which
are almost identical to ARM-USB-OCD(H) but lacking separate barrel jack
and serial console.
By suggestion from Johan Hovold it is possible to replace
ftdi_jtag_quirk with a bit more generic construction. Since all
Olimex-ARM debuggers has exactly two ports, we could safely always use
only second port within the debugger family.
Signed-off-by: Andrey Korolyov <andrey@xdel.ru>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/usb/serial/ftdi_sio.c | 8 ++++----
drivers/usb/serial/ftdi_sio_ids.h | 2 ++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 0e634c11abbf..aba74f817dc6 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -809,10 +809,10 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, FTDI_PROPOX_ISPCABLEIII_PID) },
{ USB_DEVICE(FTDI_VID, CYBER_CORTEX_AV_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
- { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID),
- .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
- { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID),
- .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_H_PID, 1) },
{ USB_DEVICE(FIC_VID, FIC_NEO1973_DEBUG_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h b/drivers/usb/serial/ftdi_sio_ids.h
index 71fb9e59db71..4fcf1cecb6d7 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -882,6 +882,8 @@
/* Olimex */
#define OLIMEX_VID 0x15BA
#define OLIMEX_ARM_USB_OCD_PID 0x0003
+#define OLIMEX_ARM_USB_TINY_PID 0x0004
+#define OLIMEX_ARM_USB_TINY_H_PID 0x002a
#define OLIMEX_ARM_USB_OCD_H_PID 0x002b
/*
--
2.13.0
^ permalink raw reply related
* patch "USB: serial: mct_u232: fix big-endian baud-rate handling" added to usb-linus
From: gregkh @ 2017-05-19 8:11 UTC (permalink / raw)
To: johan, gregkh, stable, zaitcev
This is a note to let you know that I've just added the patch titled
USB: serial: mct_u232: fix big-endian baud-rate handling
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 26cede343656c0bc2c33cdc783771282405c7fb2 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Thu, 11 May 2017 11:41:20 +0200
Subject: USB: serial: mct_u232: fix big-endian baud-rate handling
Drop erroneous cpu_to_le32 when setting the baud rate, something which
corrupted the divisor on big-endian hosts.
Found using sparse:
warning: incorrect type in argument 1 (different base types)
expected unsigned int [unsigned] [usertype] val
got restricted __le32 [usertype] <noident>
Fixes: af2ac1a091bc ("USB: serial mct_usb232: move DMA buffers to heap")
Cc: stable <stable@vger.kernel.org> # 2.6.34
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-By: Pete Zaitcev <zaitcev@yahoo.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/usb/serial/mct_u232.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/mct_u232.c b/drivers/usb/serial/mct_u232.c
index edbc81f205c2..70f346f1aa86 100644
--- a/drivers/usb/serial/mct_u232.c
+++ b/drivers/usb/serial/mct_u232.c
@@ -189,7 +189,7 @@ static int mct_u232_set_baud_rate(struct tty_struct *tty,
return -ENOMEM;
divisor = mct_u232_calculate_baud_rate(serial, value, &speed);
- put_unaligned_le32(cpu_to_le32(divisor), buf);
+ put_unaligned_le32(divisor, buf);
rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
MCT_U232_SET_BAUD_RATE_REQUEST,
MCT_U232_SET_REQUEST_TYPE,
--
2.13.0
^ permalink raw reply related
* patch "USB: serial: qcserial: add more Lenovo EM74xx device IDs" added to usb-linus
From: gregkh @ 2017-05-19 8:11 UTC (permalink / raw)
To: bjorn, johan, stable
This is a note to let you know that I've just added the patch titled
USB: serial: qcserial: add more Lenovo EM74xx device IDs
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 8d7a10dd323993cc40bd37bce8bc570133b0c396 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn@mork.no>
Date: Wed, 17 May 2017 16:30:50 +0200
Subject: USB: serial: qcserial: add more Lenovo EM74xx device IDs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
In their infinite wisdom, and never ending quest for end user frustration,
Lenovo has decided to use new USB device IDs for the wwan modules in
their 2017 laptops. The actual hardware is still the Sierra Wireless
EM7455 or EM7430, depending on region.
Cc: <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/usb/serial/qcserial.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 38b3f0d8cd58..fd509ed6cf70 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -162,6 +162,8 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x9071)}, /* Sierra Wireless MC74xx */
{DEVICE_SWI(0x1199, 0x9078)}, /* Sierra Wireless EM74xx */
{DEVICE_SWI(0x1199, 0x9079)}, /* Sierra Wireless EM74xx */
+ {DEVICE_SWI(0x1199, 0x907a)}, /* Sierra Wireless EM74xx QDL */
+ {DEVICE_SWI(0x1199, 0x907b)}, /* Sierra Wireless EM74xx */
{DEVICE_SWI(0x413c, 0x81a2)}, /* Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)}, /* Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)}, /* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
--
2.13.0
^ permalink raw reply related
* RE: [PATCH 6/8] xhci: remove GFP_DMA flag from allocation
From: David Laight @ 2017-05-19 9:10 UTC (permalink / raw)
To: 'Mathias Nyman', gregkh@linuxfoundation.org
Cc: linux-usb@vger.kernel.org, Matthias Lange, stable@vger.kernel.org
In-Reply-To: <1495035126-29091-7-git-send-email-mathias.nyman@linux.intel.com>
From: Mathias Nyman
> Sent: 17 May 2017 16:32
> There is no reason to restrict allocations to the first 16MB ISA DMA
> addresses.
>
> It is causing problems in a virtualization setup with enabled IOMMU
> (x86_64). The result is that USB is not working in the VM.
...
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 12b573c..1f1687e 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -56,7 +56,7 @@ static struct xhci_segment *xhci_segment_alloc(struct xhci_hcd *xhci,
> }
>
> if (max_packet) {
> - seg->bounce_buf = kzalloc(max_packet, flags | GFP_DMA);
> + seg->bounce_buf = kzalloc(max_packet, flags);
This might allocate memory that the device cannot access.
So can only work if dma_map_single() itself allocates a bounce buffer.
There must be a sane way to do this that doesn't ever require
double copies.
David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox