powerpc/nohash: Fix use of mmu_has_feature() in setup_initial_memory_limit()
Subsystems (8)
PATCH 1/190 powerpc/nohash: Fix use of mmu_has_feature() in setup_initial_memory_limit()
From: Michael Ellerman <[email protected]>
[ Upstream commit 4868e3508d1934d28961f940ed6b9f1e347ab52c ]
setup_initial_memory_limit() is called from early_init_devtree(), which runs prior to feature patching. If the kernel is built with CONFIG_JUMP_LABEL=y and CONFIG_JUMP_LABEL_FEATURE_CHECKS=y then we will potentially get the wrong value.
If we also have CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG=y we get a warning and backtrace:
Warning! mmu_has_feature() used prior to jump label init!
CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-rc4-gccN-next-20170331-g6af2434 #1 Call Trace: [c000000000fc3d50] [c000000000a26c30] .dump_stack+0xa8/0xe8 (unreliable) [c000000000fc3de0] [c00000000002e6b8] .setup_initial_memory_limit+0xa4/0x104 [c000000000fc3e60] [c000000000d5c23c] .early_init_devtree+0xd0/0x2f8 [c000000000fc3f00] [c000000000d5d3b0] .early_setup+0x90/0x11c [c000000000fc3f90] [c000000000000520] start_here_multiplatform+0x68/0x80
Fix it by using early_mmu_has_feature().
--- arch/powerpc/mm/tlb_nohash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/mm/tlb_nohash.c +1 -1
@@ -751,7 +751,7 @@ void setup_initial_memory_limit(phys_addr_t first_memblock_base,* avoid going over total available memory just in case... */ #ifdef CONFIG_PPC_FSL_BOOK3E -if (mmu_has_feature (MMU_FTR_TYPE_FSL_E )) { +if (early_mmu_has_feature (MMU_FTR_TYPE_FSL_E )) {unsigned long linear_sz;unsigned int num_cams;
Signature · 1 line
2.14.1
PATCH 2/190 usb: dwc2: Make sure we disconnect the gadget state
From: John Stultz <[email protected]>
[ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ]
I had seen some odd behavior with HiKey's usb-gadget interface that I finally seemed to have chased down. Basically every other time I plugged in the OTG port, the gadget interface would properly initialize. The other times, I'd get a big WARN_ON in dwc2_hsotg_init_fifo() about the fifo_map not being clear.
Ends up if we don't disconnect the gadget state, the fifo-map doesn't get cleared properly, which causes WARN_ON messages and also results in the device not properly being setup as a gadget every other time the OTG port is connected.
So this patch adds a call to dwc2_hsotg_disconnect() in the reset path so the state is properly cleared.
With it, the gadget interface initializes properly on every plug in.
--- drivers/usb/dwc2/hcd.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/dwc2/hcd.c +1 -0
@@ -3220,6 +3220,7 @@ static void dwc2_conn_id_status_change(struct work_struct *work)dwc2_core_init (hsotg, false);dwc2_enable_global_interrupts (hsotg);spin_lock_irqsave (&hsotg->lock, flags); +dwc2_hsotg_disconnect (hsotg);dwc2_hsotg_core_init_disconnected (hsotg, false);spin_unlock_irqrestore (&hsotg->lock, flags);dwc2_hsotg_core_connect (hsotg);
PATCH 3/190 usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control()
In reply to Sasha LevinFrom: Yuyang Du <[email protected]>
[ Upstream commit 9f20dfb44d03745d0d3cef2ffb3abf8d8024fa61 ]
This fixes the commit: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support").
In the case of ClearPortFeature and USB_PORT_FEAT_POWER, simply clear the right bit regardless of what the wValue is.
--- drivers/usb/gadget/udc/dummy_hcd.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-)
drivers/usb/gadget/udc/dummy_hcd.c +8 -12
@@ -2103,16 +2103,13 @@ static int dummy_hub_control( }break ;case USB_PORT_FEAT_POWER : -if (hcd->speed ==HCD_USB3 ) { -if (dum_hcd->port_status &USB_PORT_STAT_POWER ) -dev_dbg (dummy_dev (dum_hcd), -"power-off\n" ); - }else -if (dum_hcd->port_status & -USB_SS_PORT_STAT_POWER ) -dev_dbg (dummy_dev (dum_hcd), -"power-off\n" ); -/* FALLS THROUGH */ +dev_dbg (dummy_dev (dum_hcd),"power-off\n" ); +if (hcd->speed ==HCD_USB3 ) + dum_hcd->port_status &= ~USB_SS_PORT_STAT_POWER ; +else + dum_hcd->port_status &= ~USB_PORT_STAT_POWER ; +set_link_state (dum_hcd); +break ;default : dum_hcd->port_status &= ~(1 << wValue);set_link_state (dum_hcd);
@@ -2283,14 +2280,13 @@ static int dummy_hub_control(if ((dum_hcd->port_status &USB_SS_PORT_STAT_POWER ) !=0 ) { dum_hcd->port_status |= (1 << wValue); -set_link_state (dum_hcd); } }else if ((dum_hcd->port_status &USB_PORT_STAT_POWER ) !=0 ) { dum_hcd->port_status |= (1 << wValue); -set_link_state (dum_hcd); } +set_link_state (dum_hcd); }break ;case GetPortErrorCount:
Signature · 1 line
2.14.1
PATCH 4/190 perf evsel: Return exact sub event which failed with EPERM for wildcards
In reply to Sasha LevinFrom: Jin Yao <[email protected]>
[ Upstream commit 32ccb130f5325abc81b32b1a538390f46e4860f6 ]
The kernel has a special check for a specific irq_vectors trace event.
TRACE_EVENT_PERF_PERM(irq_work_exit,
is_sampling_event(p_event) ? -EPERM : 0);
The perf-record fails for this irq_vectors event when it is present, like when using a wildcard:
root@skl:/tmp# perf record -a -e irq_vectors:* sleep 2 Error: You may not have permission to collect system-wide stats.
Consider tweaking /proc/sys/kernel/perf_event_paranoid, which controls use of the performance events system by unprivileged users (without CAP_SYS_ADMIN).
The current value is 2:
-1: Allow use of (almost) all events by all users
Quoted 3 lines
= 0: Disallow raw tracepoint access by users without
CAP_IOC_LOCK= 1: Disallow CPU event access by users withoutCAP_SYS_ADMIN= 2: Disallow kernel profiling by users withoutCAP_SYS_ADMIN
To make this setting permanent, edit /etc/sysctl.conf too, e.g.:
kernel.perf_event_paranoid = -1
This patch prints out the exact sub event that failed with EPERM for wildcards to help in understanding what went wrong when this event is present:
After the patch:
root@skl:/tmp# perf record -a -e irq_vectors:* sleep 2 Error: No permission to enable irq_vectors:irq_work_exit event.
You may not have permission to collect system-wide stats.
......
Committer notes:
So we have a lot of irq_vectors events:
[root@jouet ~]# perf list irq_vectors:*
List of pre-defined events (to be used in -e):
irq_vectors:call_function_entry [Tracepoint event]
irq_vectors:call_function_exit [Tracepoint event]
irq_vectors:call_function_single_entry [Tracepoint event]
irq_vectors:call_function_single_exit [Tracepoint event]
irq_vectors:deferred_error_apic_entry [Tracepoint event]
irq_vectors:deferred_error_apic_exit [Tracepoint event]
irq_vectors:error_apic_entry [Tracepoint event]
irq_vectors:error_apic_exit [Tracepoint event]
irq_vectors:irq_work_entry [Tracepoint event]
irq_vectors:irq_work_exit [Tracepoint event]
irq_vectors:local_timer_entry [Tracepoint event]
irq_vectors:local_timer_exit [Tracepoint event]
irq_vectors:reschedule_entry [Tracepoint event]
irq_vectors:reschedule_exit [Tracepoint event]
irq_vectors:spurious_apic_entry [Tracepoint event]
irq_vectors:spurious_apic_exit [Tracepoint event]
irq_vectors:thermal_apic_entry [Tracepoint event]
irq_vectors:thermal_apic_exit [Tracepoint event]
irq_vectors:threshold_apic_entry [Tracepoint event]
irq_vectors:threshold_apic_exit [Tracepoint event]
irq_vectors:x86_platform_ipi_entry [Tracepoint event]
irq_vectors:x86_platform_ipi_exit [Tracepoint event]#
And some may be sampled:
[root@jouet ~]# perf record -e irq_vectors:local* sleep 20s [ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.020 MB perf.data (2 samples) ] [root@jouet ~]# perf report -D | egrep 'stats:|events:' Aggregated stats:
TOTAL events: 155
MMAP events: 144
COMM events: 2
EXIT events: 1
SAMPLE events: 2
MMAP2 events: 4
FINISHED_ROUND events: 1
TIME_CONV events: 1
irq_vectors:local_timer_entry stats:
TOTAL events: 1
SAMPLE events: 1
irq_vectors:local_timer_exit stats:
TOTAL events: 1
SAMPLE events: 1
[root@jouet ~]#
But, as shown in the tracepoint definition at the start of this message, some, like "irq_vectors:irq_work_exit", may not be sampled, just counted, i.e. if we try to sample, as when using 'perf record', we get an error:
[root@jouet ~]# perf record -e irq_vectors:irq_work_exit Error:
You may not have permission to collect system-wide stats.
Consider tweaking /proc/sys/kernel/perf_event_paranoid,
<SNIP>
The error message is misleading, this patch will help in pointing out what is the event causing such an error, but the error message needs improvement, i.e. we need to figure out a way to check if a tracepoint is counting only, like this one, when all we can do is to count it with 'perf stat', at most printing the delta using interval printing, as in:
[root@jouet ~]# perf stat -I 5000 -e irq_vectors:irq_work_*
# time counts unit events
5.000168871 0 irq_vectors:irq_work_entry
5.000168871 0 irq_vectors:irq_work_exit
10.000676730 0 irq_vectors:irq_work_entry
10.000676730 0 irq_vectors:irq_work_exit
15.001122415 0 irq_vectors:irq_work_entry
15.001122415 0 irq_vectors:irq_work_exit
20.001298051 0 irq_vectors:irq_work_entry
20.001298051 0 irq_vectors:irq_work_exit
25.001485020 1 irq_vectors:irq_work_entry
25.001485020 1 irq_vectors:irq_work_exit
30.001658706 0 irq_vectors:irq_work_entry
30.001658706 0 irq_vectors:irq_work_exit
^C 32.045711878 0 irq_vectors:irq_work_entry
32.045711878 0 irq_vectors:irq_work_exit[root@jouet ~]#
But at least, when we use a wildcard, this patch helps a bit.
--- tools/perf/util/evsel.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
tools/perf/util/evsel.c +7 -1
@@ -2400,11 +2400,17 @@ int perf_evsel__open_strerror(struct perf_evsel *evsel, struct target *target, int err, char *msg, size_t size) { char sbuf[STRERR_BUFSIZE]; +int printed =0 ;switch (err) {case EPERM :case EACCES : -return scnprintf (msg, size, +if (err ==EPERM ) + printed =scnprintf (msg, size, +"No permission to enable %s event.\n\n" , +perf_evsel__name (evsel)); + +return scnprintf (msg + printed, size - printed,"You may not have permission to collect %sstats.\n\n" "Consider tweaking /proc/sys/kernel/perf_event_paranoid,\n" "which controls use of the performance events system by\n"
Signature · 1 line
2.14.1
PATCH 5/190 iwlwifi: mvm: fix RX SKB header size and align it properly
In reply to Sasha LevinFrom: Johannes Berg <[email protected]>
[ Upstream commit 5cddd05c9cbe420436799716d009bc0372ef8268 ]
When receiving a frame, we currently pull in sizeof(*hdr) plus some extra (crypto/snap), which is too much, most headers aren't actually sizeof(*hdr) since that takes into account the 4-address format but doesn't take into account QoS. As a result, a typical frame will have 4 bytes of the payload in the SKB header already.
Fix this by calculating the correct header length, and now that we have that, align the end of the SKB header to a multiple of 4 so that the IP header will be aligned properly when pulled in.
--- drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-)
drivers/net/wireless/intel/iwlwifi/mvm/rx.c +15 -3
@@ -104,7 +104,20 @@ static void iwl_mvm_pass_packet_to_mac80211(struct iwl_mvm *mvm,u8 crypt_len, struct iwl_rx_cmd_buffer *rxb) { - unsigned int hdrlen, fraglen; + unsigned int hdrlen = ieee80211_hdrlen(hdr->frame_control); +unsigned int fraglen; + +/* +* The 'hdrlen' (plus the 8 bytes for the SNAP and the crypt_len, +* but those are all multiples of 4 long) all goes away, but we +* want the *end* of it, which is going to be the start of the IP +* header, to be aligned when it gets pulled in. +* The beginning of the skb->data is aligned on at least a 4-byte +* boundary after allocation. Everything here is aligned at least +* on a 2-byte boundary so we can just take hdrlen & 3 and pad by +* the result. +*/ +skb_reserve (skb, hdrlen &3 );/* If frame is small enough to fit in skb->head, pull it completely. * If not, only pull ieee80211_hdr (including crypto if present, and
@@ -118,8 +131,7 @@ static void iwl_mvm_pass_packet_to_mac80211(struct iwl_mvm *mvm,* If the latter changes (there are efforts in the standards group * to do so) we should revisit this and ieee80211_data_to_8023(). */ - hdrlen = (len <=skb_tailroom (skb)) ? len : -sizeof (*hdr) + crypt_len +8 ; + hdrlen = (len <=skb_tailroom (skb)) ? len : hdrlen + crypt_len +8 ;memcpy (skb_put (skb, hdrlen), hdr, hdrlen); fraglen = len - hdrlen;
Signature · 1 line
2.14.1
PATCH 6/190 drivers/perf: arm_pmu: handle no platform_device
In reply to Sasha LevinFrom: Mark Rutland <[email protected]>
[ Upstream commit 7654137071fa706e5c91f4f27bc2a5cd7e435a9b ]
In armpmu_dispatch_irq() we look at arm_pmu::plat_device to acquire platdata, so that we can defer to platform-specific IRQ handling, required on some 32-bit parts. With the advent of ACPI we won't always have a platform_device, and so we must avoid trying to dereference fields from it.
This patch fixes up armpmu_dispatch_irq() to avoid doing so, introducing a new armpmu_get_platdata() helper.
--- drivers/perf/arm_pmu.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/perf/arm_pmu.c +9 -3
@@ -322,10 +322,16 @@ validate_group(struct perf_event *event)return 0 ; } +static struct arm_pmu_platdata *armpmu_get_platdata (struct arm_pmu *armpmu) +{ +struct platform_device *pdev = armpmu->plat_device; + +return pdev ?dev_get_platdata (&pdev->dev) :NULL ; +} +static irqreturn_t armpmu_dispatch_irq (int irq,void *dev) {struct arm_pmu *armpmu; -struct platform_device *plat_device;struct arm_pmu_platdata *plat;int ret;u64 start_clock, finish_clock;
@@ -337,8 +343,8 @@ static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)* dereference. */ armpmu = *(void **)dev; - plat_device = armpmu->plat_device; - plat =dev_get_platdata (&plat_device->dev); + + plat =armpmu_get_platdata (armpmu); start_clock =sched_clock ();if (plat && plat->handle_irq)
Signature · 1 line
2.14.1
PATCH 7/190 perf session: Don't rely on evlist in pipe mode
In reply to Sasha LevinFrom: David Carrillo-Cisneros <[email protected]>
[ Upstream commit 0973ad97c187e06aece61f685b9c3b2d93290a73 ]
Session sets a number parameters that rely on evlist. These parameters are not used in pipe-mode and should not be set, since evlist is unavailable. Fix that.
--- tools/perf/util/session.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
tools/perf/util/session.c +13 -3
@@ -139,8 +139,14 @@ struct perf_session *perf_session__new(struct perf_data_file *file,if (perf_session__open (session) <0 ) goto out_close; -perf_session__set_id_hdr_size (session); -perf_session__set_comm_exec (session); +/* +* set session attributes that are present in perf.data +* but not in pipe-mode. +*/ +if (!file->is_pipe) { +perf_session__set_id_hdr_size (session); +perf_session__set_comm_exec (session); + } } }else { session->machines.host.env = &perf_env;
@@ -155,7 +161,11 @@ struct perf_session *perf_session__new(struct perf_data_file *file,pr_warning ("Cannot read kernel map\n" ); } -if (tool && tool->ordering_requires_timestamps && +/* +* In pipe-mode, evlist is empty until PERF_RECORD_HEADER_ATTR is +* processed, so perf_evlist__sample_id_all is not meaningful here. +*/ +if ((!file || !file->is_pipe) && tool && tool->ordering_requires_timestamps && tool->ordered_events && !perf_evlist__sample_id_all (session->evlist)) {dump_printf ("WARNING: No sample_id_all support, falling back to unordered processing\n" ); tool->ordered_events = false;
Signature · 1 line
2.14.1
PATCH 8/190 vfio/powerpc/spapr_tce: Enforce IOMMU type compatibility check
In reply to Sasha LevinFrom: Alexey Kardashevskiy <[email protected]>
[ Upstream commit 1282ba7fc28dbc66c3f0e4aaafaaa228361d1ae5 ]
The existing SPAPR TCE driver advertises both VFIO_SPAPR_TCE_IOMMU and VFIO_SPAPR_TCE_v2_IOMMU types to the userspace and the userspace usually picks the v2.
Normally the userspace would create a container, attach an IOMMU group to it and only then set the IOMMU type (which would normally be v2).
However a specific IOMMU group may not support v2, in other words it may not implement set_window/unset_window/take_ownership/ release_ownership and such a group should not be attached to a v2 container.
This adds extra checks that a new group can do what the selected IOMMU type suggests. The userspace can then test the return value from ioctl(VFIO_SET_IOMMU, VFIO_SPAPR_TCE_v2_IOMMU) and try VFIO_SPAPR_TCE_IOMMU.
--- drivers/vfio/vfio_iommu_spapr_tce.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/vfio/vfio_iommu_spapr_tce.c +8 -0
@@ -1332,8 +1332,16 @@ static int tce_iommu_attach_group(void *iommu_data,if (!table_group->ops || !table_group->ops->take_ownership || !table_group->ops->release_ownership) { +if (container->v2) { + ret = -EPERM ; + goto unlock_exit; + } ret =tce_iommu_take_ownership (container, table_group); }else { +if (!container->v2) { + ret = -EPERM ; + goto unlock_exit; + } ret =tce_iommu_take_ownership_ddw (container, table_group);if (!tce_groups_attached (container) && !container->tables[0 ]) container->def_window_pending = true;
Signature · 1 line
2.14.1
PATCH 9/190 vfio/spapr_tce: Check kzalloc() return when preregistering memory
In reply to Sasha LevinFrom: Alexey Kardashevskiy <[email protected]>
[ Upstream commit 3393af24b665cb0aea7353b05e522b03ab1e7d73 ]
This adds missing checking for kzalloc() return value.
--- drivers/vfio/vfio_iommu_spapr_tce.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/vfio/vfio_iommu_spapr_tce.c +5 -0
@@ -195,6 +195,11 @@ static long tce_iommu_register_pages(struct tce_container *container,return ret; tcemem =kzalloc (sizeof (*tcemem),GFP_KERNEL ); +if (!tcemem) { +mm_iommu_put (container->mm, mem); +return -ENOMEM ; + } + tcemem->mem = mem;list_add (&tcemem->next, &container->prereg_list);
Signature · 1 line
2.14.1
PATCH 10/190 scsi: sg: check for valid direction before starting the request
In reply to Sasha LevinFrom: Johannes Thumshirn <[email protected]>
[ Upstream commit 28676d869bbb5257b5f14c0c95ad3af3a7019dd5 ]
Check for a valid direction before starting the request, otherwise we risk running into an assertion in the scsi midlayer checking for valid requests.
[mkp: fixed typo]
--- drivers/scsi/sg.c | 46 ++++++++++++++++++++++++++++++++++------------ 1 file changed, 34 insertions(+), 12 deletions(-)
drivers/scsi/sg.c +34 -12
@@ -663,18 +663,14 @@ sg_write(struct file *filp, const char __user *buf, size_t count, loff_t * ppos)* is a non-zero input_size, so emit a warning. */ if (hp->dxfer_direction ==SG_DXFER_TO_FROM_DEV ) { -static char cmd[TASK_COMM_LEN ]; -if (strcmp (current->comm, cmd)) { -printk_ratelimited (KERN_WARNING -"sg_write: data in/out %d/%d bytes " -"for SCSI command 0x%x-- guessing " -"data in;\n program %s not setting " -"count and/or reply_len properly\n" , - old_hdr.reply_len - (int )SZ_SG_HEADER , - input_size, (unsigned int ) cmnd[0 ], - current->comm); -strcpy (cmd, current->comm); - } +printk_ratelimited (KERN_WARNING +"sg_write: data in/out %d/%d bytes " +"for SCSI command 0x%x-- guessing " +"data in;\n program %s not setting " +"count and/or reply_len properly\n" , + old_hdr.reply_len - (int )SZ_SG_HEADER , + input_size, (unsigned int ) cmnd[0 ], + current->comm); } k =sg_common_write (sfp, srp, cmnd, sfp->timeout, blocking);return (k <0 ) ? k : count;
@@ -753,6 +749,29 @@ sg_new_write(Sg_fd *sfp, struct file *file, const char __user *buf,return count; } +static bool sg_is_valid_dxfer (sg_io_hdr_t *hp) +{ +switch (hp->dxfer_direction) { +case SG_DXFER_NONE : +if (hp->dxferp || hp->dxfer_len >0 ) +return false; +return true; +case SG_DXFER_TO_DEV : +case SG_DXFER_FROM_DEV : +case SG_DXFER_TO_FROM_DEV : +if (!hp->dxferp || hp->dxfer_len ==0 ) +return false; +return true; +case SG_DXFER_UNKNOWN : +if ((!hp->dxferp && hp->dxfer_len) || + (hp->dxferp && hp->dxfer_len ==0 )) +return false; +return true; +default : +return false; + } +} +static int sg_common_write (Sg_fd * sfp,Sg_request * srp,unsigned char *cmnd,int timeout,int blocking)
@@ -773,6 +792,9 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,"sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n" , (int) cmnd[0], (int) hp->cmd_len)); +if (!sg_is_valid_dxfer (hp)) +return -EINVAL ; + k =sg_start_req (srp, cmnd);if (k) { SCSI_LOG_TIMEOUT(1, sg_printk(KERN_INFO, sfp->parentdp,
Signature · 1 line
2.14.1
PATCH 11/190 scsi: sg: close race condition in sg_remove_sfp_usercontext()
In reply to Sasha LevinFrom: Hannes Reinecke <[email protected]>
[ Upstream commit 97d27b0dd015e980ade63fda111fd1353276e28b ]
sg_remove_sfp_usercontext() is clearing any sg requests, but needs to take 'rq_list_lock' when modifying the list.
--- drivers/scsi/sg.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/scsi/sg.c +10 -2
@@ -524,6 +524,7 @@ sg_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) }else count = (old_hdr->result ==0 ) ?0 : -EIO ;sg_finish_rem_req (srp); +sg_remove_request (sfp, srp); retval = count; free_old_hdr:kfree (old_hdr);
@@ -564,6 +565,7 @@ sg_new_read(Sg_fd * sfp, char __user *buf, size_t count, Sg_request * srp) } err_out: err2 =sg_finish_rem_req (srp); +sg_remove_request (sfp, srp);return err ? : err2 ? : count; }
@@ -800,6 +802,7 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,SCSI_LOG_TIMEOUT (1 ,sg_printk (KERN_INFO , sfp->parentdp,"sg_common_write: start_req err=%d\n" , k));sg_finish_rem_req (srp); +sg_remove_request (sfp, srp);return k;/* probably out of space --> ENOMEM */ }if (atomic_read (&sdp->detaching)) {
@@ -812,6 +815,7 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp, }sg_finish_rem_req (srp); +sg_remove_request (sfp, srp);return -ENODEV ; }
@@ -1302,6 +1306,7 @@ sg_rq_end_io_usercontext(struct work_struct *work)struct sg_fd *sfp = srp->parentfp;sg_finish_rem_req (srp); +sg_remove_request (sfp, srp);kref_put (&sfp->f_ref, sg_remove_sfp); }
@@ -1846,8 +1851,6 @@ sg_finish_rem_req(Sg_request *srp)else sg_remove_scat (sfp, req_schp); -sg_remove_request (sfp, srp); -return ret; }
@@ -2194,12 +2197,17 @@ sg_remove_sfp_usercontext(struct work_struct *work) struct sg_fd *sfp = container_of(work, struct sg_fd, ew.work);struct sg_device *sdp = sfp->parentdp;Sg_request *srp; +unsigned long iflags;/* Cleanup any responses which were never read(). */ +write_lock_irqsave (&sfp->rq_list_lock, iflags);while (!list_empty (&sfp->rq_list)) { srp =list_first_entry (&sfp->rq_list, Sg_request, entry);sg_finish_rem_req (srp); +list_del (&srp->entry); + srp->parentfp =NULL ; } +write_unlock_irqrestore (&sfp->rq_list_lock, iflags);if (sfp->reserve.bufflen >0 ) { SCSI_LOG_TIMEOUT(6, sg_printk(KERN_INFO, sdp,
Signature · 1 line
2.14.1
PATCH 12/190 ALSA: hda: Add Geminilake id to SKL_PLUS
In reply to Sasha LevinFrom: "Subhransu S. Prusty" <[email protected]>
[ Upstream commit 12ee4022f67f8854061b46e5c0a7ad6258ab66c2 ]
Geminilake is Skylake family platform. So add it's id to skl_plus check.
--- sound/pci/hda/hda_intel.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
sound/pci/hda/hda_intel.c +3 -1
@@ -369,8 +369,10 @@ enum {#define IS_KBL_LP (pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x9d71)#define IS_KBL_H (pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa2f0)#define IS_BXT (pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98) +#define IS_GLK (pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x3198)#define IS_SKL_PLUS (pci) (IS_SKL(pci) || IS_SKL_LP(pci) || IS_BXT(pci)) || \ - IS_KBL(pci) || IS_KBL_LP(pci) || IS_KBL_H(pci) + IS_KBL(pci) || IS_KBL_LP(pci) || IS_KBL_H(pci) || \ + IS_GLK(pci)static char *driver_short_names[] = { [AZX_DRIVER_ICH ] ="HDA Intel" ,
Signature · 1 line
2.14.1
PATCH 13/190 kprobes/x86: Fix kprobe-booster not to boost far call instructions
In reply to Sasha LevinFrom: Masami Hiramatsu <[email protected]>
[ Upstream commit bd0b90676c30fe640e7ead919b3e38846ac88ab7 ]
Fix the kprobe-booster not to boost far call instruction, because a call may store the address in the single-step execution buffer to the stack, which should be modified after single stepping.
Currently, this instruction will be filtered as not boostable in resume_execution(), so this is not a critical issue.
--- arch/x86/kernel/kprobes/core.c | 2 ++ 1 file changed, 2 insertions(+)
arch/x86/kernel/kprobes/core.c +2 -0
@@ -199,6 +199,8 @@ int can_boost(kprobe_opcode_t *opcodes, void *addr)return (opcode !=0x62 && opcode !=0x67 );case 0x70 :return 0 ;/* can't boost conditional jump */ +case 0x90 : +return opcode !=0x9a ;/* can't boost call far */ case 0xc0 :/* can't boost software-interruptions */ return (0xc1 < opcode && opcode <0xcc ) || opcode ==0xcf ;
Signature · 1 line
2.14.1
PATCH 14/190 kprobes/x86: Set kprobes pages read-only
In reply to Sasha LevinFrom: Masami Hiramatsu <[email protected]>
[ Upstream commit d0381c81c2f782fa2131178d11e0cfb23d50d631 ]
Set the pages which is used for kprobes' singlestep buffer and optprobe's trampoline instruction buffer to readonly. This can prevent unexpected (or unintended) instruction modification.
This also passes rodata_test as below.
Without this patch, rodata_test shows a warning:
WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:235 note_page+0x7a9/0xa20 x86/mm: Found insecure W+X mapping at address ffffffffa0000000/0xffffffffa0000000
With this fix, no W+X pages are found:
x86/mm: Checked W+X mappings: passed, no W+X pages found.
rodata_test: all tests were successful
--- arch/x86/kernel/kprobes/core.c | 4 ++++ arch/x86/kernel/kprobes/opt.c | 3 +++ 2 files changed, 7 insertions(+)
arch/x86/kernel/kprobes/core.c +4 -0
@@ -409,6 +409,8 @@ static int arch_copy_kprobe(struct kprobe *p) {int ret; +set_memory_rw ((unsigned long )p->ainsn.insn &PAGE_MASK ,1 ); +/* Copy an instruction with recovering if other optprobe modifies it.*/ ret =__copy_instruction (p->ainsn.insn, p->addr);if (!ret)
@@ -423,6 +425,8 @@ static int arch_copy_kprobe(struct kprobe *p)else p->ainsn.boostable =-1 ; +set_memory_ro ((unsigned long )p->ainsn.insn &PAGE_MASK ,1 ); +/* Check whether the instruction modifies Interrupt Flag or not */ p->ainsn.if_modifier =is_IF_modifier (p->ainsn.insn);
arch/x86/kernel/kprobes/opt.c +3 -0
@@ -371,6 +371,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe *op, } buf = (u8 *)op->optinsn.insn; +set_memory_rw ((unsigned long )buf &PAGE_MASK ,1 );/* Copy instructions into the out-of-line buffer */ ret =copy_optimized_instructions (buf +TMPL_END_IDX , op->kp.addr);
@@ -393,6 +394,8 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe *op,synthesize_reljump (buf +TMPL_END_IDX + op->optinsn.size, (u8 *)op->kp.addr + op->optinsn.size); +set_memory_ro ((unsigned long )buf &PAGE_MASK ,1 ); +flush_icache_range ((unsigned long ) buf, (unsigned long ) buf +TMPL_END_IDX + op->optinsn.size +RELATIVEJUMP_SIZE );
Signature · 1 line
2.14.1
PATCH 15/190 pwm: tegra: Increase precision in PWM rate calculation
In reply to Sasha LevinFrom: Laxman Dewangan <[email protected]>
[ Upstream commit 250b76f43f57d578ebff5e7211eb2c73aa5cd6ca ]
The rate of the PWM calculated as follows:
hz = NSEC_PER_SEC / period_ns;
rate = (rate + (hz / 2)) / hz;
This has the precision loss in lower PWM rate.
Change this to have more precision as:
hz = DIV_ROUND_CLOSEST_ULL(NSEC_PER_SEC * 100, period_ns); rate = DIV_ROUND_CLOSEST(rate * 100, hz)
Example:
1. period_ns = 16672000, PWM clock rate is 200 KHz.
Based on old formula hz = NSEC_PER_SEC / period_ns = 1000000000ul/16672000 = 59 (59.98) rate = (200K + 59/2)/59 = 3390 Based on new method: hz = 5998 rate = DIV_ROUND_CLOSE(200000*100, 5998) = 3334 If we measure the PWM signal rate, we will get more accurate period with rate value of 3334 instead of 3390.
2. period_ns = 16803898, PWM clock rate is 200 KHz.
Based on old formula: hz = 59, rate = 3390 Based on new formula: hz = 5951, rate = 3360 The PWM signal rate of 3360 is more near to requested period than 3333.
--- drivers/pwm/pwm-tegra.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/pwm/pwm-tegra.c +5 -2
@@ -76,6 +76,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,struct tegra_pwm_chip *pc =to_tegra_pwm_chip (chip);unsigned long long c = duty_ns;unsigned long rate, hz; +unsigned long long ns100 =NSEC_PER_SEC ;u32 val =0 ;int err;
@@ -95,9 +96,11 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,* cycles at the PWM clock rate will take period_ns nanoseconds. */ rate =clk_get_rate (pc->clk) >>PWM_DUTY_WIDTH ; - hz =NSEC_PER_SEC / period_ns; - rate = (rate + (hz /2 )) / hz; +/* Consider precision in PWM_SCALE_WIDTH rate calculation */ + ns100 *=100 ; + hz =DIV_ROUND_CLOSEST_ULL (ns100, period_ns); + rate =DIV_ROUND_CLOSEST (rate *100 , hz);/* * Since the actual PWM divider is the register's frequency divider
Signature · 1 line
2.14.1
PATCH 16/190 clk: qcom: msm8996: Fix the vfe1 powerdomain name
In reply to Sasha LevinFrom: Rajendra Nayak <[email protected]>
[ Upstream commit a62ca337b36e31621b582cbe8f17d9404a48e120 ]
Fix a typo which caused both vfe0 and vfe1 powerdomains to be named as vfe0.
--- drivers/clk/qcom/mmcc-msm8996.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/qcom/mmcc-msm8996.c +1 -1
@@ -2984,7 +2984,7 @@ static struct gdsc vfe1_gdsc = { .cxcs = (unsigned int []){ 0x36ac }, .cxc_count = 1, .pd = { - .name = "vfe0", + .name = "vfe1", }, .parent = &camss_gdsc.pd, .pwrsts = PWRSTS_OFF_ON,
Signature · 1 line
2.14.1
PATCH 17/190 Bluetooth: Avoid bt_accept_unlink() double unlinking
In reply to Sasha LevinFrom: Dean Jenkins <[email protected]>
[ Upstream commit 27bfbc21a0c0f711fa5382de026c7c0700c9ea28 ]
There is a race condition between a thread calling bt_accept_dequeue() and a different thread calling bt_accept_unlink(). Protection against concurrency is implemented using sk locking. However, sk locking causes serialisation of the bt_accept_dequeue() and bt_accept_unlink() threads. This serialisation can cause bt_accept_dequeue() to obtain the sk from the parent list but becomes blocked waiting for the sk lock held by the bt_accept_unlink() thread. bt_accept_unlink() unlinks sk and this thread releases the sk lock unblocking bt_accept_dequeue() which potentially runs bt_accept_unlink() again on the same sk causing a crash. The attempt to double unlink the same sk from the parent list can cause a NULL pointer dereference crash due to bt_sk(sk)->parent becoming NULL on the first unlink, followed by the second unlink trying to execute bt_sk(sk)->parent->sk_ack_backlog-- in bt_accept_unlink() which crashes.
When sk is in the parent list, bt_sk(sk)->parent will be not be NULL. When sk is removed from the parent list, bt_sk(sk)->parent is set to NULL. Therefore, add a defensive check for bt_sk(sk)->parent not being NULL to ensure that sk is still in the parent list after the sk lock has been taken in bt_accept_dequeue(). If bt_sk(sk)->parent is detected as being NULL then restart the loop so that the loop variables are refreshed to use the latest values. This is necessary as list_for_each_entry_safe() is not thread safe so causing a risk of an infinite loop occurring as sk could point to itself.
In addition, in bt_accept_dequeue() increase the sk reference count to protect against early freeing of sk. Early freeing can be possible if the bt_accept_unlink() thread calls l2cap_sock_kill() or rfcomm_sock_kill() functions before bt_accept_dequeue() gets the sk lock.
For test purposes, the probability of failure can be increased by putting a msleep of 1 second in bt_accept_dequeue() between getting the sk and waiting for the sk lock. This exposes the fact that the loop list_for_each_entry_safe(p, n, &bt_sk(parent)->accept_q) is not safe from threads that unlink sk from the list in parallel with the loop which can cause sk to become stale within the loop.
--- net/bluetooth/af_bluetooth.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
net/bluetooth/af_bluetooth.c +24 -0
@@ -163,6 +163,9 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk) }EXPORT_SYMBOL (bt_accept_enqueue); +/* Calling function must hold the sk lock. +* bt_sk(sk)->parent must be non-NULL meaning sk is in the parent list. +*/ void bt_accept_unlink (struct sock *sk) {BT_DBG ("sk %p state %d" , sk, sk->sk_state);
@@ -181,11 +184,32 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)BT_DBG ("parent %p" , parent); +restart:list_for_each_entry_safe (s, n, &bt_sk (parent)->accept_q, accept_q) { sk = (struct sock *)s; +/* Prevent early freeing of sk due to unlink and sock_kill */ +sock_hold (sk);lock_sock (sk); +/* Check sk has not already been unlinked via +* bt_accept_unlink() due to serialisation caused by sk locking +*/ +if (!bt_sk (sk)->parent) { +BT_DBG ("sk %p, already unlinked" , sk); +release_sock (sk); +sock_put (sk); + +/* Restart the loop as sk is no longer in the list +* and also avoid a potential infinite loop because +* list_for_each_entry_safe() is not thread safe. +*/ + goto restart; + } + +/* sk is safely in the parent list so reduce reference count */ +sock_put (sk); +/* FIXME: Is this check still needed */ if (sk->sk_state ==BT_CLOSED ) {bt_accept_unlink (sk);
Signature · 1 line
2.14.1
PATCH 18/190 Bluetooth: 6lowpan: fix delay work init in add_peer_chan()
In reply to Sasha LevinFrom: Michael Scott <[email protected]>
[ Upstream commit d2891c4d071d807f01cc911dc42a68f4568d65cf ]
When adding 6lowpan devices very rapidly we sometimes see a crash:
[23122.306615] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0-43-arm64 #1 Debian 4.9.9.linaro.43-1 [23122.315400] Hardware name: HiKey Development Board (DT) [23122.320623] task: ffff800075443080 task.stack: ffff800075484000 [23122.326551] PC is at expire_timers+0x70/0x150 [23122.330907] LR is at run_timer_softirq+0xa0/0x1a0 [23122.335616] pc : [<ffff000008142dd8>] lr : [<ffff000008142f58>] pstate: 600001c5
This was due to add_peer_chan() unconditionally initializing the lowpan_btle_dev->notify_peers delayed work structure, even if the lowpan_btle_dev passed into add_peer_chan() had previously been initialized.
Normally, this would go unnoticed as the delayed work timer is set for 100 msec, however when calling add_peer_chan() faster than 100 msec it clears out a previously queued delay work causing the crash above.
To fix this, let add_peer_chan() know when a new lowpan_btle_dev is passed in so that it only performs the delay work initialization when needed.
--- net/bluetooth/6lowpan.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
net/bluetooth/6lowpan.c +7 -3
@@ -755,7 +755,8 @@ static void set_ip_addr_bits(u8 addr_type, u8 *addr) }static struct l2cap_chan *add_peer_chan (struct l2cap_chan *chan, -struct lowpan_btle_dev *dev) +struct lowpan_btle_dev *dev, +bool new_netdev) {struct lowpan_peer *peer;
@@ -786,7 +787,8 @@ static struct l2cap_chan *add_peer_chan(struct l2cap_chan *chan,spin_unlock (&devices_lock);/* Notifying peers about us needs to be done without locks held */ -INIT_DELAYED_WORK (&dev->notify_peers, do_notify_peers); +if (new_netdev) +INIT_DELAYED_WORK (&dev->notify_peers, do_notify_peers);schedule_delayed_work (&dev->notify_peers,msecs_to_jiffies (100 ));return peer->chan;
@@ -843,6 +845,7 @@ static int setup_netdev(struct l2cap_chan *chan, struct lowpan_btle_dev **dev)static inline void chan_ready_cb (struct l2cap_chan *chan) {struct lowpan_btle_dev *dev; +bool new_netdev = false; dev =lookup_dev (chan->conn);
@@ -853,12 +856,13 @@ static inline void chan_ready_cb(struct l2cap_chan *chan)l2cap_chan_del (chan, -ENOENT );return ; } + new_netdev = true; }if (!try_module_get (THIS_MODULE ))return ; -add_peer_chan (chan, dev); +add_peer_chan (chan, dev, new_netdev);ifup (dev->netdev); }
Signature · 1 line
2.14.1
PATCH 19/190 mac80211_hwsim: use per-interface power level
In reply to Sasha LevinFrom: Johannes Berg <[email protected]>
[ Upstream commit 1d5e9f80ab021e3e1f9436627a4ad07a143ccb2c ]
When channel contexts are used, there's no global power level (the power_level is always 0). Use the per-interface TX power in mac80211_hwsim to have a proper setting for both cases.
This fixes the bgscan_simple and bgscan_learn test cases when the number of channels advertised by hwsim is >1 by default.
--- drivers/net/wireless/mac80211_hwsim.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
drivers/net/wireless/mac80211_hwsim.c +3 -6
@@ -552,8 +552,6 @@ struct mac80211_hwsim_data {/* wmediumd portid responsible for netgroup of this radio */ u32 wmediumd; -int power_level; -/* difference between this hw's clock and the real clock, in usecs */ s64 tsf_offset;s64 bcn_delta;
@@ -1208,7 +1206,9 @@ static bool mac80211_hwsim_tx_frame_no_nl(struct ieee80211_hw *hw,if (info->control.rates[0 ].flags &IEEE80211_TX_RC_SHORT_GI ) rx_status.flag |=RX_FLAG_SHORT_GI ;/* TODO: simulate real signal strength (and optional packet loss) */ - rx_status.signal = data->power_level -50 ; + rx_status.signal =-50 ; +if (info->control.vif) + rx_status.signal += info->control.vif->bss_conf.txpower;if (data->ps !=PS_DISABLED ) hdr->frame_control |=cpu_to_le16 (IEEE80211_FCTL_PM );
@@ -1607,7 +1607,6 @@ static int mac80211_hwsim_config(struct ieee80211_hw *hw, u32 changed)WARN_ON (data->channel && data->use_chanctx); - data->power_level = conf->power_level;if (!data->started || !data->beacon_int)tasklet_hrtimer_cancel (&data->beacon_timer);else if (!hrtimer_is_queued (&data->beacon_timer.timer)) {
@@ -2212,7 +2211,6 @@ static const char mac80211_hwsim_gstrings_stats[][ETH_GSTRING_LEN] = {"d_tx_failed" ,"d_ps_mode" , "d_group", - "d_tx_power", };#define MAC80211_HWSIM_SSTATS_LEN ARRAY_SIZE(mac80211_hwsim_gstrings_stats)
@@ -2249,7 +2247,6 @@ static void mac80211_hwsim_get_et_stats(struct ieee80211_hw *hw, data[i++] = ar->tx_failed; data[i++] = ar->ps; data[i++] = ar->group; - data[i++] = ar->power_level;WARN_ON (i !=MAC80211_HWSIM_SSTATS_LEN ); }
Signature · 1 line
2.14.1
PATCH 20/190 ath10k: fix compile time sanity check for CE4 buffer size
In reply to Sasha LevinFrom: Mohammed Shafi Shajakhan <[email protected]>
[ Upstream commit 62ca0690cd495bb7c1414cdf0cf790c2922a1d79 ]
In 'ath10k_ce_alloc_pipe' the compile time sanity check to ensure that there is sufficient buffers in CE4 for HTT Tx MSDU descriptors, but this did not take into account of the case with 'peer flow control' enabled, fix this.
--- drivers/net/wireless/ath/ath10k/ce.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/ath/ath10k/ce.c +1 -1
@@ -1059,7 +1059,7 @@ int ath10k_ce_alloc_pipe(struct ath10k *ar, int ce_id,*/ BUILD_BUG_ON (2 *TARGET_NUM_MSDU_DESC > (CE_HTT_H2T_MSG_SRC_NENTRIES -1 )); -BUILD_BUG_ON (2 *TARGET_10X_NUM_MSDU_DESC > +BUILD_BUG_ON (2 *TARGET_10_4_NUM_MSDU_DESC_PFC > (CE_HTT_H2T_MSG_SRC_NENTRIES -1 ));BUILD_BUG_ON (2 *TARGET_TLV_NUM_MSDU_DESC > (CE_HTT_H2T_MSG_SRC_NENTRIES -1 ));
Signature · 1 line
2.14.1
PATCH 21/190 wil6210: fix protection against connections during reset
In reply to Sasha LevinFrom: Hamad Kadmany <[email protected]>
[ Upstream commit b819447dfc4bd120c9d6cd8521252d544fce8fe7 ]
Existing code that ignores connection events during reset flow will never take effect since it locks the same mutex taken by the reset flow.
In addition, in case of unsolicited disconnect events ignore those as well since device is about to get reset.
--- drivers/net/wireless/ath/wil6210/wmi.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/net/wireless/ath/wil6210/wmi.c +9 -2
@@ -501,16 +501,16 @@ static void wmi_evt_connect(struct wil6210_priv *wil, int id, void *d, int len) assoc_resp_ielen =0 ; } -mutex_lock (&wil->mutex);if (test_bit (wil_status_resetting, wil->status) || !test_bit (wil_status_fwready, wil->status)) {wil_err (wil,"status_resetting, cancel connect event, CID %d\n" , evt->cid); -mutex_unlock (&wil->mutex);/* no need for cleanup, wil_reset will do that */ return ; } +mutex_lock (&wil->mutex); +if ((wdev->iftype ==NL80211_IFTYPE_STATION ) || (wdev->iftype ==NL80211_IFTYPE_P2P_CLIENT )) {if (!test_bit (wil_status_fwconnecting, wil->status)) {
@@ -608,6 +608,13 @@ static void wmi_evt_disconnect(struct wil6210_priv *wil, int id, wil->sinfo_gen++; +if (test_bit (wil_status_resetting, wil->status) || + !test_bit (wil_status_fwready, wil->status)) { +wil_err (wil,"status_resetting, cancel disconnect event\n" ); +/* no need for cleanup, wil_reset will do that */ +return ; + } +mutex_lock (&wil->mutex);wil6210_disconnect (wil, evt->bssid, reason_code, true);mutex_unlock (&wil->mutex);
Signature · 1 line
2.14.1
PATCH 22/190 wil6210: fix memory access violation in wil_memcpy_from/toio_32
In reply to Sasha LevinFrom: Dedy Lansky <[email protected]>
[ Upstream commit 0f6edfe2bbbb59d161580cb4870fcc46f5490f85 ]
In case count is not multiple of 4, there is a read access in wil_memcpy_toio_32() from outside src buffer boundary.
In wil_memcpy_fromio_32(), in case count is not multiple of 4, there is a write access to outside dst io memory boundary.
Fix these issues with proper handling of the last 1 to 4 copied bytes.
--- drivers/net/wireless/ath/wil6210/main.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)
drivers/net/wireless/ath/wil6210/main.c +17 -3
@@ -129,9 +129,15 @@ void wil_memcpy_fromio_32(void *dst, const volatile void __iomem *src,u32 *d = dst;const volatile u32 __iomem *s = src; -/* size_t is unsigned, if (count%4 != 0) it will wrap */ -for (count +=4 ; count >4 ; count -=4 ) +for (; count >=4 ; count -=4 ) *d++ =__raw_readl (s++); + +if (unlikely (count)) { +/* count can be 1..3 */ +u32 tmp =__raw_readl (s); + +memcpy (d, &tmp, count); + } } void wil_memcpy_fromio_halp_vote(struct wil6210_priv *wil, void *dst,
@@ -148,8 +154,16 @@ void wil_memcpy_toio_32(volatile void __iomem *dst, const void *src,volatile u32 __iomem *d = dst;const u32 *s = src; -for (count +=4 ; count >4 ; count -=4 ) +for (; count >=4 ; count -=4 )__raw_writel (*s++, d++); + +if (unlikely (count)) { +/* count can be 1..3 */ +u32 tmp =0 ; + +memcpy (&tmp, s, count); +__raw_writel (tmp, d); + } } void wil_memcpy_toio_halp_vote(struct wil6210_priv *wil,
Signature · 1 line
2.14.1
PATCH 23/190 perf stat: Fix bug in handling events in error state
In reply to Sasha LevinFrom: Stephane Eranian <[email protected]>
[ Upstream commit db49a71798a38f3ddf3f3462703328dca39b1ac7 ]
(This is a patch has been sitting in the Intel CQM/CMT driver series for
a while, despite not depend on it. Sending it now independently since the series is being discarded.)
When an event is in error state, read() returns 0 instead of sizeof() buffer. In certain modes, such as interval printing, ignoring the 0 return value may cause bogus count deltas to be computed and thus invalid results printed.
This patch fixes this problem by modifying read_counters() to mark the event as not scaled (scaled = -1) to force the printout routine to show <NOT COUNTED>.
--- tools/perf/builtin-stat.c | 12 +++++++++--- tools/perf/util/evsel.c | 4 ++-- 2 files changed, 11 insertions(+), 5 deletions(-)
tools/perf/builtin-stat.c +9 -3
@@ -310,8 +310,12 @@ static int read_counter(struct perf_evsel *counter)struct perf_counts_values *count; count =perf_counts (counter->counts, cpu, thread); -if (perf_evsel__read (counter, cpu, thread, count)) +if (perf_evsel__read (counter, cpu, thread, count)) { + counter->counts->scaled =-1 ; +perf_counts (counter->counts, cpu, thread)->ena =0 ; +perf_counts (counter->counts, cpu, thread)->run =0 ;return -1 ; + }if (STAT_RECORD ) {if (perf_evsel__write_stat_event (counter, cpu, thread, count)) {
@@ -336,12 +340,14 @@ static int read_counter(struct perf_evsel *counter)static void read_counters (void ) {struct perf_evsel *counter; +int ret;evlist__for_each_entry (evsel_list, counter) { -if (read_counter (counter)) + ret =read_counter (counter); +if (ret)pr_debug ("failed to read counter %s\n" , counter->name); -if (perf_stat_process_counter (&stat_config, counter)) +if (ret ==0 &&perf_stat_process_counter (&stat_config, counter))pr_warning ("failed to process counter %s\n" , counter->name); } }
tools/perf/util/evsel.c +2 -2
@@ -1221,7 +1221,7 @@ int perf_evsel__read(struct perf_evsel *evsel, int cpu, int thread,if (FD (evsel, cpu, thread) <0 )return -EINVAL ; -if (readn (FD (evsel, cpu, thread), count,sizeof (*count)) <0 ) +if (readn (FD (evsel, cpu, thread), count,sizeof (*count)) <=0 )return -errno;return 0 ;
@@ -1239,7 +1239,7 @@ int __perf_evsel__read_on_cpu(struct perf_evsel *evsel,if (evsel->counts ==NULL &&perf_evsel__alloc_counts (evsel, cpu +1 , thread +1 ) <0 )return -ENOMEM ; -if (readn (FD (evsel, cpu, thread), &count, nv *sizeof (u64)) <0 ) +if (readn (FD (evsel, cpu, thread), &count, nv *sizeof (u64)) <=0 )return -errno;perf_evsel__compute_deltas (evsel, cpu, thread, &count);
Signature · 1 line
2.14.1
PATCH 24/190 mwifiex: Fix invalid port issue
In reply to Sasha LevinFrom: Ganapathi Bhat <[email protected]>
[ Upstream commit ecd7eb7c2bcf99f6c23d68ad56ce15949da848a1 ]
We have to use start port, for TX/RX of single packet, instead of current aggregating port. This will fix SDIO CMD53(TX/RX) returning -ETIMEDOUT and halting the data path.
--- drivers/net/wireless/marvell/mwifiex/sdio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/marvell/mwifiex/sdio.c +2 -2
@@ -1458,7 +1458,7 @@ static int mwifiex_sdio_card_to_host_mp_aggr(struct mwifiex_adapter *adapter, }if (card->mpa_rx.pkt_cnt ==1 ) - mport = adapter->ioport + port; + mport = adapter->ioport + card->mpa_rx.start_port;if (mwifiex_read_data_sync (adapter, card->mpa_rx.buf, card->mpa_rx.buf_len, mport,1 ))
@@ -1891,7 +1891,7 @@ static int mwifiex_host_to_card_mp_aggr(struct mwifiex_adapter *adapter, }if (card->mpa_tx.pkt_cnt ==1 ) - mport = adapter->ioport + port; + mport = adapter->ioport + card->mpa_tx.start_port; ret =mwifiex_write_data_to_card (adapter, card->mpa_tx.buf, card->mpa_tx.buf_len, mport);
Signature · 1 line
2.14.1
PATCH 25/190 platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA
In reply to Sasha LevinFrom: Santeri Toivonen <[email protected]>
[ Upstream commit f35823619db8bbaa2afea8705f239c3cecb9d22f ]
Asus laptop X302UA starts up with Wi-Fi disabled, without a way to enable it. Set wapf=4 to fix the problem.
--- drivers/platform/x86/asus-nb-wmi.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/platform/x86/asus-nb-wmi.c +9 -0
@@ -150,6 +150,15 @@ static const struct dmi_system_id asus_quirks[] = {*/ .driver_data = &quirk_asus_wapf4, }, + { + .callback = dmi_matched, + .ident = "ASUSTeK COMPUTER INC. X302UA", + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK COMPUTER INC." ), + DMI_MATCH(DMI_PRODUCT_NAME, "X302UA"), + }, + .driver_data = &quirk_asus_wapf4, + }, { .callback = dmi_matched, .ident = "ASUSTeK COMPUTER INC. X401U",
Signature · 1 line
2.14.1
Re: [PATCH AUTOSEL for 4.9 025/190] platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA
Quoted 10 lines · Sasha Levin
From: Santeri Toivonen <[email protected]>
[ Upstream commit
f35823619db8bbaa2afea8705f239c3cecb9d22f]Asus laptop X302UA starts up with Wi-Fi disabled, without a way to enable it. Set wapf=4 to fix the problem.
Signed-off-by Santeri Toivonen <[email protected]>Signed-off-by Darren Hart (VMware) <[email protected]>Signed-off-by Sasha Levin <[email protected]>
Hi Sasha,
I'm curious about this AUTOSEL tag, and what about this patch triggered its selection?
Pulling changes like this can be risky if they aren't done sequentially, resulting in the stable driver having a spotty patching. I don't necessarily object to *this* patch, but in general, I want to understand what triggers the selection of patches that maintainers have not tagged with stable and which do not contain fixes tags.
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Greg KH
maintainerRe: [PATCH AUTOSEL for 4.9 025/190] platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA
Quoted 8 lines · Darren Hart
Quoted 7 lines · Sasha Levin
From: Santeri Toivonen <[email protected]>
[ Upstream commit
f35823619db8bbaa2afea8705f239c3cecb9d22f]Asus laptop X302UA starts up with Wi-Fi disabled, without a way to enable it. Set wapf=4 to fix the problem.
Quoted 8 lines
Quoted 3 lines
Signed-off-by Santeri Toivonen <[email protected]>Signed-off-by Darren Hart (VMware) <[email protected]>Signed-off-by Sasha Levin <[email protected]>Hi Sasha,
I'm curious about this AUTOSEL tag, and what about this patch triggered its selection?
It's "magic"! :)
Seriously, it's close to magic, there's a tool that Sasha is using that takes "machine learning" to match patches that we have not applied in stable kernels to ones that we have, and try to catch those that we forgot to tag for the stable tree. Not all subsystems mark stable patches, so this is an attempt to catch those fixes that should be getting backported but are not either because the developer/maintainer forgot to mark it as such, or because they just never mark those types of patches.
Sasha has a better write up about how this all works somewhere, and given that this type of question keeps coming up every other week or so, I think I need to add it to a FAQ somewhere to point people at to make it more obvious what is happening.
thanks,
greg k-h
Re: [PATCH AUTOSEL for 4.9 025/190] platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA
Quoted 29 lines · Greg KH
Quoted 8 lines · Darren Hart
Quoted 7 lines · Sasha Levin
From: Santeri Toivonen <[email protected]>
[ Upstream commit
f35823619db8bbaa2afea8705f239c3cecb9d22f]Asus laptop X302UA starts up with Wi-Fi disabled, without a way to enable it. Set wapf=4 to fix the problem.
Quoted 8 lines
Quoted 3 lines
Signed-off-by Santeri Toivonen <[email protected]>Signed-off-by Darren Hart (VMware) <[email protected]>Signed-off-by Sasha Levin <[email protected]>Hi Sasha,
I'm curious about this AUTOSEL tag, and what about this patch triggered its selection?
It's "magic"! :)
Seriously, it's close to magic, there's a tool that Sasha is using that takes "machine learning" to match patches that we have not applied in stable kernels to ones that we have, and try to catch those that we forgot to tag for the stable tree. Not all subsystems mark stable patches, so this is an attempt to catch those fixes that should be getting backported but are not either because the developer/maintainer forgot to mark it as such, or because they just never mark those types of patches.
Quoted 4 lines
Sasha has a better write up about how this all works somewhere, and given that this type of question keeps coming up every other week or so, I think I need to add it to a FAQ somewhere to point people at to make it more obvious what is happening.
It's pretty much a neural network that knows how to classify a "bug fixing patch" based on things such as:
- Code metrics
- Words in the commit message (the NN knows about the 10,000 most used words, and their likehood to appear in a bug fixing patch).
- Which files were modified.
- Authors of the commit, and persons who got Cc'ed/Signed-off/etc.
So in this case, there are a few things that "helped" this patch get selected:
- The word "quirk" in the subject line.
- "fix" + "problem" in the commit log.
- Modifies drivers/platform/x86/asus-nb-wmi.c which contains mostly quirks.
- The patch has minimal changes in code metrics. I don't have exact numbers for this, but it seems that in general patches that do very
little have more odds of fixing bugs.
And I also manually review all the stuff that get sent out, and to my human brain it looks like something that should be in stable :)
Signature · 2 lines
Thanks, Sasha
Re: [PATCH AUTOSEL for 4.9 025/190] platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA
Quoted 55 lines · Sasha Levin
Quoted 29 lines · Greg KH
Quoted 8 lines · Darren Hart
Quoted 7 lines · Sasha Levin
From: Santeri Toivonen <[email protected]>
[ Upstream commit
f35823619db8bbaa2afea8705f239c3cecb9d22f]Asus laptop X302UA starts up with Wi-Fi disabled, without a way to enable it. Set wapf=4 to fix the problem.
Quoted 8 lines
Quoted 3 lines
Signed-off-by Santeri Toivonen <[email protected]>Signed-off-by Darren Hart (VMware) <[email protected]>Signed-off-by Sasha Levin <[email protected]>Hi Sasha,
I'm curious about this AUTOSEL tag, and what about this patch triggered its selection?
It's "magic"! :)
Seriously, it's close to magic, there's a tool that Sasha is using that takes "machine learning" to match patches that we have not applied in stable kernels to ones that we have, and try to catch those that we forgot to tag for the stable tree. Not all subsystems mark stable patches, so this is an attempt to catch those fixes that should be getting backported but are not either because the developer/maintainer forgot to mark it as such, or because they just never mark those types of patches.
Quoted 4 lines
Sasha has a better write up about how this all works somewhere, and given that this type of question keeps coming up every other week or so, I think I need to add it to a FAQ somewhere to point people at to make it more obvious what is happening.
It's pretty much a neural network that knows how to classify a "bug fixing patch" based on things such as:
- Code metrics
- Words in the commit message (the NN knows about the 10,000 most used words, and their likehood to appear in a bug fixing patch).
- Which files were modified.
- Authors of the commit, and persons who got Cc'ed/Signed-off/etc.So in this case, there are a few things that "helped" this patch get selected:
- The word "quirk" in the subject line.
- "fix" + "problem" in the commit log.
- Modifiesdrivers/platform/x86/asus-nb-wmi.cwhich contains mostly quirks.
- The patch has minimal changes in code metrics. I don't have exact numbers for this, but it seems that in general patches that do very
little have more odds of fixing bugs.
Quoted 2 lines
And I also manually review all the stuff that get sent out, and to my human brain it looks like something that should be in stable :)
This is really cool to see, thanks for the effort here. Good place for the application of AI/ML.
Have you considered having this work on patches submitted? If the machine could respond to patches that don't have stable or fixes tags that it thinks should, we could address this a bit earlier in the process, and perhaps get a more consistent labeling, as well as get the maintainer eyes on this, reducing the amount of manual auditing you have to do.
Quoted 5 lines
Signature · 4 lines
-- Thanks, Sasha
Signature · 2 lines
Darren Hart VMware Open Source Technology Center
Re: [PATCH AUTOSEL for 4.9 025/190] platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA
Quoted 59 lines · Darren Hart
Quoted 55 lines · Sasha Levin
Quoted 29 lines · Greg KH
Quoted 8 lines · Darren Hart
Quoted 7 lines · Sasha Levin
From: Santeri Toivonen <[email protected]>
[ Upstream commit
f35823619db8bbaa2afea8705f239c3cecb9d22f]Asus laptop X302UA starts up with Wi-Fi disabled, without a way to enable it. Set wapf=4 to fix the problem.
Quoted 8 lines
Quoted 3 lines
Signed-off-by Santeri Toivonen <[email protected]>Signed-off-by Darren Hart (VMware) <[email protected]>Signed-off-by Sasha Levin <[email protected]>Hi Sasha,
I'm curious about this AUTOSEL tag, and what about this patch triggered its selection?
It's "magic"! :)
Seriously, it's close to magic, there's a tool that Sasha is using that takes "machine learning" to match patches that we have not applied in stable kernels to ones that we have, and try to catch those that we forgot to tag for the stable tree. Not all subsystems mark stable patches, so this is an attempt to catch those fixes that should be getting backported but are not either because the developer/maintainer forgot to mark it as such, or because they just never mark those types of patches.
Quoted 4 lines
Sasha has a better write up about how this all works somewhere, and given that this type of question keeps coming up every other week or so, I think I need to add it to a FAQ somewhere to point people at to make it more obvious what is happening.
It's pretty much a neural network that knows how to classify a "bug fixing patch" based on things such as:
- Code metrics
- Words in the commit message (the NN knows about the 10,000 most used words, and their likehood to appear in a bug fixing patch).
- Which files were modified.
- Authors of the commit, and persons who got Cc'ed/Signed-off/etc.So in this case, there are a few things that "helped" this patch get selected:
- The word "quirk" in the subject line.
- "fix" + "problem" in the commit log.
- Modifiesdrivers/platform/x86/asus-nb-wmi.cwhich contains mostly quirks.
- The patch has minimal changes in code metrics. I don't have exact numbers for this, but it seems that in general patches that do very
little have more odds of fixing bugs.Quoted 2 lines
And I also manually review all the stuff that get sent out, and to my human brain it looks like something that should be in stable :)
Quoted 8 lines
This is really cool to see, thanks for the effort here. Good place for the application of AI/ML.
Have you considered having this work on patches submitted? If the machine could respond to patches that don't have stable or fixes tags that it thinks should, we could address this a bit earlier in the process, and perhaps get a more consistent labeling, as well as get the maintainer eyes on this, reducing the amount of manual auditing you have to do.
Yup, there are a few ideas on how to get this done earlier in the process such as integration with checkpatch and a mail bot a-la 0day.
Right now it's still in the experimentation phase, I'm trying to improve the results based on review feedback I get from maintainers/authors.
A good example of the above was that the NN was very keen on including commits that added devicetree bindings since those usually happen with hardware enablement which usually goes in stable. The issue was that sometimes the code for the hardware didn't exist back in older stable trees, and building the kernel wouldn't catch this error, so it's one of the things I'm hoping to deal with before it goes too public.
Signature · 2 lines
Thanks, Sasha
PATCH 26/190 bonding: handle link transition from FAIL to UP correctly
In reply to Sasha LevinFrom: Mahesh Bandewar <[email protected]>
[ Upstream commit fb9eb899a6dc663e4a2deed9af2ac28f507d0ffb ]
When link transitions from LINK_FAIL to LINK_UP, the commit phase is not called. This leads to an erroneous state causing slave-link state to get stuck in "going down" state while its speed and duplex are perfectly fine. This issue is a side-effect of splitting link-set into propose and commit phases introduced by de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring")
This patch fixes these issues by calling commit phase whenever link state change is proposed.
--- drivers/net/bonding/bond_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/bonding/bond_main.c +2 -1
@@ -2063,6 +2063,7 @@ static int bond_miimon_inspect(struct bonding *bond) (bond->params.downdelay - slave->delay) * bond->params.miimon, slave->dev->name); + commit++;continue ; }
@@ -2100,7 +2101,7 @@ static int bond_miimon_inspect(struct bonding *bond) (bond->params.updelay - slave->delay) * bond->params.miimon, slave->dev->name); - + commit++;continue ; }
Signature · 1 line
2.14.1
PATCH 27/190 regulator: anatop: set default voltage selector for pcie
In reply to Sasha LevinFrom: Dong Aisheng <[email protected]>
[ Upstream commit 9bf944548169f6153c3d3778cf983cb5db251a0e ]
Set the initial voltage selector for vddpcie in case it's disabled by default.
This fixes the below warning:
20c8000.anatop:regulator-vddpcie: Failed to read a valid default voltage selector.anatop_regulator: probe of 20c8000.anatop:regulator-vddpcie failed with error -22
--- drivers/regulator/anatop-regulator.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/regulator/anatop-regulator.c +5 -0
@@ -296,6 +296,11 @@ static int anatop_regulator_probe(struct platform_device *pdev)if (!sreg->sel && !strcmp (sreg->name,"vddpu" )) sreg->sel =22 ; +/* set the default voltage of the pcie phy to be 1.100v */ +if (!sreg->sel && rdesc->name && + !strcmp (rdesc->name,"vddpcie" )) + sreg->sel =0x10 ; +if (!sreg->bypass && !sreg->sel) {dev_err (&pdev->dev,"Failed to read a valid default voltage selector.\n" );return -EINVAL ;
Signature · 1 line
2.14.1
PATCH 28/190 power: supply: bq24190_charger: Limit over/under voltage fault logging
In reply to Sasha LevinFrom: Liam Breck <[email protected]>
[ Upstream commit d63d07c6fc25182af6d3ab5b3b8737b0c1025ebd ]
If the charger is unplugged before the battery is full we may see an over/under voltage fault. Ignore this rather then emitting a message or uevent.
This fixes messages like these getting logged on charger unplug + replug:
bq24190-charger 15-006b: Fault: boost 0, charge 1, battery 0, ntc 0 bq24190-charger 15-006b: Fault: boost 0, charge 0, battery 0, ntc 0
--- drivers/power/supply/bq24190_charger.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/power/supply/bq24190_charger.c +6 -1
@@ -1184,8 +1184,13 @@ static irqreturn_t bq24190_irq_handler_thread(int irq, void *data) } }while (f_reg && ++i <2 ); +/* ignore over/under voltage fault after disconnect */ +if (f_reg == (1 <<BQ24190_REG_F_CHRG_FAULT_SHIFT ) && + !(ss_reg &BQ24190_REG_SS_PG_STAT_MASK )) + f_reg =0 ; +if (f_reg != bdi->f_reg) { - dev_info(bdi->dev, + dev_warn(bdi->dev, "Fault: boost %d, charge %d, battery %d, ntc %d\n", !!(f_reg & BQ24190_REG_F_BOOST_FAULT_MASK), !!(f_reg & BQ24190_REG_F_CHRG_FAULT_MASK),
Signature · 1 line
2.14.1
PATCH 29/190 x86: i8259: export legacy_pic symbol
In reply to Sasha LevinFrom: Hans de Goede <[email protected]>
[ Upstream commit 7ee06cb2f840a96be46233181ed4557901a74385 ]
The classic PC rtc-coms driver has a workaround for broken ACPI device nodes for it which lack an irq resource. This workaround used to unconditionally hardcode the irq to 8 in these cases.
This was causing irq conflict problems on systems without a legacy-pic so a recent patch added an if (nr_legacy_irqs()) guard to the workaround to avoid this irq conflict.
nr_legacy_irqs() uses the legacy_pic symbol under the hood causing an undefined symbol error if the rtc-cmos code is build as a module.
This commit exports the legacy_pic symbol to fix this.
--- arch/x86/kernel/i8259.c | 1 + 1 file changed, 1 insertion(+)
arch/x86/kernel/i8259.c +0 -0
@@ -418,6 +418,7 @@ struct legacy_pic default_legacy_pic =3D { };
=20
struct legacy_pic *legacy_pic =3D &default_legacy_pic;
+EXPORT_SYMBOL(legacy_pic);
=20
static int __init i8259A_init_ops(void)
{
--=20
2.14.1
PATCH 30/190 rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs
In reply to Sasha LevinFrom: Hans de Goede <[email protected]>
[ Upstream commit a1e23a42f1bdc00e32fc4869caef12e4e6272f26 ]
On some systems (e.g. Intel Bay Trail systems) the legacy PIC is not used, in this case virq 8 will be a random irq, rather then hw_irq 8 from the PIC.
Requesting virq 8 in this case will not help us to get alarm irqs and may cause problems for other drivers which actually do need virq 8, for example on an Asus Transformer T100TA this leads to:
[ 28.745155] genirq: Flags mismatch irq 8. 00000088 (mmc0) vs. 00000080 (rtc0) <snip oops> [ 28.753700] mmc0: Failed to request IRQ 8: -16 [ 28.975934] sdhci-acpi: probe of 80860F14:01 failed with error -16
This commit fixes this by making the rtc-cmos driver continue without using an irq rather then claiming irq 8 when no irq is specified in the pnp-info and there are no legacy-irqs.
--- drivers/rtc/rtc-cmos.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
drivers/rtc/rtc-cmos.c +13 -4
@@ -41,6 +41,9 @@#include <linux/pm.h> #include <linux/of.h> #include <linux/of_platform.h> +#ifdef CONFIG_X86 +#include <asm/i8259.h> +#endif /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */ #include <linux/mc146818rtc.h>
@@ -1117,17 +1120,23 @@ static int cmos_pnp_probe(struct pnp_dev *pnp, const struct pnp_device_id *id) {cmos_wake_setup (&pnp->dev); -if (pnp_port_start (pnp,0 ) ==0x70 && !pnp_irq_valid (pnp,0 )) +if (pnp_port_start (pnp,0 ) ==0x70 && !pnp_irq_valid (pnp,0 )) { +unsigned int irq =0 ; +#ifdef CONFIG_X86 /* Some machines contain a PNP entry for the RTC, but * don't define the IRQ. It should always be safe to -* hardcode it in these cases +* hardcode it on systems with a legacy PIC. */ +if (nr_legacy_irqs ()) + irq =8 ; +#endif return cmos_do_probe (&pnp->dev, -pnp_get_resource (pnp,IORESOURCE_IO ,0 ),8 ); -else +pnp_get_resource (pnp,IORESOURCE_IO ,0 ), irq); + }else {return cmos_do_probe (&pnp->dev,pnp_get_resource (pnp,IORESOURCE_IO ,0 ),pnp_irq (pnp,0 )); + } }static void cmos_pnp_remove (struct pnp_dev *pnp)
Signature · 1 line
2.14.1
PATCH 31/190 Input: ar1021_i2c - fix too long name in driver's device table
In reply to Sasha LevinFrom: Dmitry Torokhov <[email protected]>
[ Upstream commit 95123fc43560d6f4a60e74f72836e63cd8848f76 ]
The name field in structure i2c_device_id is 20 characters, and we expect it to be NULL-terminated, however we are trying to stuff it with 21 bytes and thus NULL-terminator is lost. This causes issues when one creates device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the last "C", and automatic module loading by alias does not work as result.
The -I2C suffix in the device name is superfluous, we know what bus we are dealing with, so let's drop it. Also, no other driver uses capitals, and the manufacturer name is normally not included, except in very rare cases of incompatible name collisions.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
--- drivers/input/touchscreen/ar1021_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/input/touchscreen/ar1021_i2c.c +1 -1
@@ -152,7 +152,7 @@ static int __maybe_unused ar1021_i2c_resume(struct device *dev) static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend, ar1021_i2c_resume);static const struct i2c_device_id ar1021_i2c_id[] = { - {"MICROCHIP_AR1021_I2C" ,0 }, + {"ar1021" ,0 }, { }, };MODULE_DEVICE_TABLE (i2c, ar1021_i2c_id);
Signature · 1 line
2.14.1
PATCH 32/190 time: Change posix clocks ops interfaces to use timespec64
In reply to Sasha LevinFrom: Deepa Dinamani <[email protected]>
[ Upstream commit d340266e19ddb70dbd608f9deedcfb35fdb9d419 ]
struct timespec is not y2038 safe on 32 bit machines.
The posix clocks apis use struct timespec directly and through struct itimerspec.
Replace the posix clock interfaces to use struct timespec64 and struct itimerspec64 instead. Also fix up their implementations accordingly.
Note that the clock_getres() interface has also been changed to use timespec64 even though this particular interface is not affected by the y2038 problem. This helps verification for internal kernel code for y2038 readiness by getting rid of time_t/ timeval/ timespec.
--- drivers/ptp/ptp_clock.c | 18 +++++++----------- include/linux/posix-clock.h | 10 +++++----- kernel/time/posix-clock.c | 34 ++++++++++++++++++++++++---------- 3 files changed, 36 insertions(+), 26 deletions(-)
drivers/ptp/ptp_clock.c +7 -11
@@ -97,30 +97,26 @@ static s32 scaled_ppm_to_ppb(long ppm)/* posix clock implementation */ -static int ptp_clock_getres (struct posix_clock *pc,struct timespec *tp) +static int ptp_clock_getres (struct posix_clock *pc,struct timespec64 *tp) { tp->tv_sec =0 ; tp->tv_nsec =1 ;return 0 ; } -static int ptp_clock_settime (struct posix_clock *pc,const struct timespec *tp) +static int ptp_clock_settime (struct posix_clock *pc,const struct timespec64 *tp) { struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock); -struct timespec64 ts =timespec_to_timespec64 (*tp); -return ptp->info->settime64 (ptp->info, &ts); +return ptp->info->settime64 (ptp->info, tp); } -static int ptp_clock_gettime (struct posix_clock *pc,struct timespec *tp) +static int ptp_clock_gettime (struct posix_clock *pc,struct timespec64 *tp) { struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock); -struct timespec64 ts;int err; - err = ptp->info->gettime64 (ptp->info, &ts); -if (!err) - *tp =timespec64_to_timespec (ts); + err = ptp->info->gettime64 (ptp->info, tp);return err; }
@@ -133,7 +129,7 @@ static int ptp_clock_adjtime(struct posix_clock *pc, struct timex *tx) ops = ptp->info;if (tx->modes &ADJ_SETOFFSET ) { -struct timespec ts; +struct timespec64 ts;ktime_t kt;s64 delta;
@@ -146,7 +142,7 @@ static int ptp_clock_adjtime(struct posix_clock *pc, struct timex *tx)if ((unsigned long ) ts.tv_nsec >=NSEC_PER_SEC )return -EINVAL ; - kt =timespec_to_ktime (ts); + kt =timespec64_to_ktime (ts); delta =ktime_to_ns (kt); err = ops->adjtime (ops, delta); }else if (tx->modes &ADJ_FREQUENCY ) {
include/linux/posix-clock.h +5 -5
@@ -59,23 +59,23 @@ struct posix_clock_operations {int (*clock_adjtime)(struct posix_clock *pc,struct timex *tx); -int (*clock_gettime)(struct posix_clock *pc,struct timespec *ts); +int (*clock_gettime)(struct posix_clock *pc,struct timespec64 *ts); -int (*clock_getres) (struct posix_clock *pc,struct timespec *ts); +int (*clock_getres) (struct posix_clock *pc,struct timespec64 *ts);int (*clock_settime)(struct posix_clock *pc, -const struct timespec *ts); +const struct timespec64 *ts);int (*timer_create) (struct posix_clock *pc,struct k_itimer *kit);int (*timer_delete) (struct posix_clock *pc,struct k_itimer *kit);void (*timer_gettime)(struct posix_clock *pc, -struct k_itimer *kit,struct itimerspec *tsp); +struct k_itimer *kit,struct itimerspec64 *tsp);int (*timer_settime)(struct posix_clock *pc,struct k_itimer *kit,int flags, -struct itimerspec *tsp,struct itimerspec *old); +struct itimerspec64 *tsp,struct itimerspec64 *old);/* * Optional character device methods: */
kernel/time/posix-clock.c +24 -10
@@ -300,14 +300,17 @@ static int pc_clock_adjtime(clockid_t id, struct timex *tx)static int pc_clock_gettime (clockid_t id,struct timespec *ts) {struct posix_clock_desc cd; +struct timespec64 ts64;int err; err =get_clock_desc (id, &cd);if (err)return err; -if (cd.clk->ops.clock_gettime) - err = cd.clk->ops.clock_gettime (cd.clk, ts); +if (cd.clk->ops.clock_gettime) { + err = cd.clk->ops.clock_gettime (cd.clk, &ts64); + *ts =timespec64_to_timespec (ts64); + }else err = -EOPNOTSUPP ;
@@ -319,14 +322,17 @@ static int pc_clock_gettime(clockid_t id, struct timespec *ts)static int pc_clock_getres (clockid_t id,struct timespec *ts) {struct posix_clock_desc cd; +struct timespec64 ts64;int err; err =get_clock_desc (id, &cd);if (err)return err; -if (cd.clk->ops.clock_getres) - err = cd.clk->ops.clock_getres (cd.clk, ts); +if (cd.clk->ops.clock_getres) { + err = cd.clk->ops.clock_getres (cd.clk, &ts64); + *ts =timespec64_to_timespec (ts64); + }else err = -EOPNOTSUPP ;
@@ -337,6 +343,7 @@ static int pc_clock_getres(clockid_t id, struct timespec *ts)static int pc_clock_settime (clockid_t id,const struct timespec *ts) { +struct timespec64 ts64 =timespec_to_timespec64 (*ts);struct posix_clock_desc cd;int err;
@@ -350,7 +357,7 @@ static int pc_clock_settime(clockid_t id, const struct timespec *ts) }if (cd.clk->ops.clock_settime) - err = cd.clk->ops.clock_settime (cd.clk, ts); + err = cd.clk->ops.clock_settime (cd.clk, &ts64);else err = -EOPNOTSUPP ; out:
@@ -403,29 +410,36 @@ static void pc_timer_gettime(struct k_itimer *kit, struct itimerspec *ts) {clockid_t id = kit->it_clock;struct posix_clock_desc cd; +struct itimerspec64 ts64;if (get_clock_desc (id, &cd))return ; -if (cd.clk->ops.timer_gettime) - cd.clk->ops.timer_gettime (cd.clk, kit, ts); - +if (cd.clk->ops.timer_gettime) { + cd.clk->ops.timer_gettime (cd.clk, kit, &ts64); + *ts =itimerspec64_to_itimerspec (&ts64); + }put_clock_desc (&cd); }static int pc_timer_settime (struct k_itimer *kit,int flags,struct itimerspec *ts,struct itimerspec *old) { +struct itimerspec64 ts64 =itimerspec_to_itimerspec64 (ts);clockid_t id = kit->it_clock;struct posix_clock_desc cd; +struct itimerspec64 old64;int err; err =get_clock_desc (id, &cd);if (err)return err; -if (cd.clk->ops.timer_settime) - err = cd.clk->ops.timer_settime (cd.clk, kit, flags, ts, old); +if (cd.clk->ops.timer_settime) { + err = cd.clk->ops.timer_settime (cd.clk, kit, flags, &ts64, &old64); +if (old) + *old =itimerspec64_to_itimerspec (&old64); + }else err = -EOPNOTSUPP ;
Signature · 1 line
2.14.1
PATCH 33/190 ACPI/processor: Fix error handling in __acpi_processor_start()
In reply to Sasha LevinFrom: Thomas Gleixner <[email protected]>
[ Upstream commit a5cbdf693a60d5b86d4d21dfedd90f17754eb273 ]
When acpi_install_notify_handler() fails the cooling device stays registered and the sysfs files created via acpi_pss_perf_init() are leaked and the function returns success.
Undo acpi_pss_perf_init() and return a proper error code.
--- drivers/acpi/processor_driver.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/acpi/processor_driver.c +3 -0
@@ -251,6 +251,9 @@ static int __acpi_processor_start(struct acpi_device *device)if (ACPI_SUCCESS (status))return 0 ; + result = -ENODEV ; +acpi_pss_perf_exit (pr, device); + err_power_exit:acpi_processor_power_exit (pr);return result;
Signature · 1 line
2.14.1
PATCH 34/190 ACPI/processor: Replace racy task affinity logic
In reply to Sasha LevinFrom: Thomas Gleixner <[email protected]>
[ Upstream commit 8153f9ac43897f9f4786b30badc134fcc1a4fb11 ]
acpi_processor_get_throttling() requires to invoke the getter function on the target CPU. This is achieved by temporarily setting the affinity of the calling user space thread to the requested CPU and reset it to the original affinity afterwards.
That's racy vs. CPU hotplug and concurrent affinity settings for that thread resulting in code executing on the wrong CPU and overwriting the new affinity setting.
acpi_processor_get_throttling() is invoked in two ways:
1) The CPU online callback, which is already running on the target CPU and obviously protected against hotplug and not affected by affinity settings.
2) The ACPI driver probe function, which is not protected against hotplug during modprobe.
Switch it over to work_on_cpu() and protect the probe function against CPU hotplug.
--- drivers/acpi/processor_driver.c | 7 ++++- drivers/acpi/processor_throttling.c | 62 +++++++++++++++++++++---------------- 2 files changed, 42 insertions(+), 27 deletions(-)
drivers/acpi/processor_driver.c +6 -1
@@ -262,11 +262,16 @@ static int __acpi_processor_start(struct acpi_device *device)static int acpi_processor_start (struct device *dev) {struct acpi_device *device =ACPI_COMPANION (dev); +int ret;if (!device)return -ENODEV ; -return __acpi_processor_start (device); +/* Protect against concurrent CPU hotplug operations */ +get_online_cpus (); + ret =__acpi_processor_start (device); +put_online_cpus (); +return ret; }static int acpi_processor_stop (struct device *dev)
drivers/acpi/processor_throttling.c +36 -26
116 lines not on this page · raw message
Signature · 1 line
2.14.1
PATCH 35/190 cpufreq/sh: Replace racy task affinity logic
In reply to Sasha LevinFrom: Thomas Gleixner <[email protected]>
[ Upstream commit 205dcc1ecbc566cbc20acf246e68de3b080b3ecf ]
The target() callback must run on the affected cpu. This is achieved by temporarily setting the affinity of the calling thread to the requested CPU and reset it to the original affinity afterwards.
That's racy vs. concurrent affinity settings for that thread resulting in code executing on the wrong CPU.
Replace it by work_on_cpu(). All call pathes which invoke the callbacks are already protected against CPU hotplug.
--- drivers/cpufreq/sh-cpufreq.c | 45 ++++++++++++++++++++++++++------------------ 1 file changed, 27 insertions(+), 18 deletions(-)
drivers/cpufreq/sh-cpufreq.c +27 -18
@@ -30,54 +30,63 @@ static DEFINE_PER_CPU(struct clk, sh_cpuclk); +struct cpufreq_target { +struct cpufreq_policy *policy; +unsigned int freq; +}; +static unsigned int sh_cpufreq_get (unsigned int cpu) {return (clk_get_rate (&per_cpu (sh_cpuclk, cpu)) +500 ) /1000 ; } -/* -* Here we notify other drivers of the proposed change and the final change. -*/ -static int sh_cpufreq_target (struct cpufreq_policy *policy, -unsigned int target_freq, -unsigned int relation) +static long __sh_cpufreq_target (void *arg) { -unsigned int cpu = policy->cpu; +struct cpufreq_target *target = arg; +struct cpufreq_policy *policy = target->policy; +int cpu = policy->cpu;struct clk *cpuclk = &per_cpu (sh_cpuclk, cpu); -cpumask_t cpus_allowed;struct cpufreq_freqs freqs;struct device *dev;long freq; - cpus_allowed = current->cpus_allowed; -set_cpus_allowed_ptr (current,cpumask_of (cpu)); - -BUG_ON (smp_processor_id () != cpu); +if (smp_processor_id () != cpu) +return -ENODEV ; dev =get_cpu_device (cpu);/* Convert target_freq from kHz to Hz */ - freq =clk_round_rate (cpuclk, target_freq *1000 ); + freq =clk_round_rate (cpuclk, target->freq *1000 );if (freq < (policy->min *1000 ) || freq > (policy->max *1000 ))return -EINVAL ; -dev_dbg (dev,"requested frequency %u Hz\n" , target_freq *1000 ); +dev_dbg (dev,"requested frequency %u Hz\n" , target->freq *1000 ); freqs.old =sh_cpufreq_get (cpu); freqs.new = (freq +500 ) /1000 ; freqs.flags =0 ; -cpufreq_freq_transition_begin (policy, &freqs); -set_cpus_allowed_ptr (current, &cpus_allowed); +cpufreq_freq_transition_begin (target->policy, &freqs);clk_set_rate (cpuclk, freq); -cpufreq_freq_transition_end (policy, &freqs,0 ); +cpufreq_freq_transition_end (target->policy, &freqs,0 );dev_dbg (dev,"set frequency %lu Hz\n" , freq); -return 0 ; } +/* +* Here we notify other drivers of the proposed change and the final change. +*/ +static int sh_cpufreq_target (struct cpufreq_policy *policy, +unsigned int target_freq, +unsigned int relation) +{ +struct cpufreq_target data = { .policy = policy, .freq = target_freq }; + +return work_on_cpu (policy->cpu, __sh_cpufreq_target, &data); +} +static int sh_cpufreq_verify (struct cpufreq_policy *policy) {struct clk *cpuclk = &per_cpu (sh_cpuclk, policy->cpu);
Signature · 1 line
2.14.1
PATCH 36/190 genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs
In reply to Sasha LevinFrom: Hans de Goede <[email protected]>
[ Upstream commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 ]
When requesting a shared irq with IRQF_TRIGGER_NONE then the irqaction flags get filled with the trigger type from the irq_data:
if (!(new->flags & IRQF_TRIGGER_MASK))
new->flags |= irqd_get_trigger_type(&desc->irq_data);On the first setup_irq() the trigger type in irq_data is NONE when the above code executes, then the irq is started up for the first time and then the actual trigger type gets established, but that's too late to fix up new->flags.
When then a second user of the irq requests the irq with IRQF_TRIGGER_NONE its irqaction's triggertype gets set to the actual trigger type and the following check fails:
if (!((old->flags ^ new->flags) & IRQF_TRIGGER_MASK))
Resulting in the request_irq failing with -EBUSY even though both users requested the irq with IRQF_SHARED | IRQF_TRIGGER_NONE
Fix this by comparing the new irqaction's trigger type to the trigger type stored in the irq_data which correctly reflects the actual trigger type being used for the irq.
--- kernel/irq/manage.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
kernel/irq/manage.c +3 -1
@@ -1210,8 +1210,10 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)* set the trigger type must match. Also all must * agree on ONESHOT. */ +unsigned int oldtype =irqd_get_trigger_type (&desc->irq_data); +if (!((old->flags & new->flags) &IRQF_SHARED ) || - ((old->flags ^ new->flags) &IRQF_TRIGGER_MASK ) || + (oldtype != (new->flags &IRQF_TRIGGER_MASK )) || ((old->flags ^ new->flags) &IRQF_ONESHOT )) goto mismatch;
Signature · 1 line
2.14.1
PATCH 37/190 i2c: i2c-scmi: add a MS HID
In reply to Sasha LevinFrom: Edgar Cherkasov <[email protected]>
[ Upstream commit e058e7a4bc89104540a8a303682248614b5df6f1 ]
Description of the problem:
- i2c-scmi driver contains only two identifiers "SMBUS01" and "SMBUSIBM";
- the fist HID (SMBUS01) is clearly defined in "SMBus Control Method Interface Specification, version 1.0": "Each device must specify 'SMBUS01' as its _HID and use a unique _UID value";
- unfortunately, BIOS vendors (like AMI) seem to ignore this requirement and implement "SMB0001" HID instead of "SMBUS01";
- I speculate that they do this because only "SMB0001" is hard coded in Windows SMBus driver produced by Microsoft.
This leads to following situation:
- SMBus works out of box in Windows but not in Linux;
- board vendors are forced to add correct "SMBUS01" HID to BIOS to make SMBus work in Linux. Moreover the same board vendors complain that tools (3-rd party ASL compiler) do not like the "SMBUS01" identifier and produce errors. So they need to constantly patch the compiler for each new version of BIOS.
As it is very unlikely that BIOS vendors implement a correct HID in future, I would propose to consider whether it is possible to work around the problem by adding MS HID to the Linux i2c-scmi driver.
v2: move the definition of the new HID to the driver itself.
--- drivers/i2c/busses/i2c-scmi.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/i2c/busses/i2c-scmi.c +4 -0
@@ -18,6 +18,9 @@#define ACPI_SMBUS_HC_CLASS "smbus"#define ACPI_SMBUS_HC_DEVICE_NAME "cmi" +/* SMBUS HID definition as supported by Microsoft Windows */ +#define ACPI_SMBUS_MS_HID "SMB0001" +ACPI_MODULE_NAME ("smbus_cmi" );struct smbus_methods_t {
@@ -51,6 +54,7 @@ static const struct smbus_methods_t ibm_smbus_methods = {static const struct acpi_device_id acpi_smbus_cmi_ids[] = { {"SMBUS01" , (kernel_ulong_t)&smbus_methods}, {ACPI_SMBUS_IBM_HID , (kernel_ulong_t)&ibm_smbus_methods}, + {ACPI_SMBUS_MS_HID , (kernel_ulong_t)&smbus_methods}, {"" ,0 } };MODULE_DEVICE_TABLE (acpi, acpi_smbus_cmi_ids);
Signature · 1 line
2.14.1
PATCH 38/190 net: ipv6: send unsolicited NA on admin up
In reply to Sasha LevinFrom: David Ahern <[email protected]>
[ Upstream commit 4a6e3c5def13c91adf2acc613837001f09af3baa ]
ndisc_notify is the ipv6 equivalent to arp_notify. When arp_notify is set to 1, gratuitous arp requests are sent when the device is brought up. The same is expected when ndisc_notify is set to 1 (per ndisc_notify in Documentation/networking/ip-sysctl.txt). The NA is not sent on NETDEV_UP event; add it.
--- net/ipv6/ndisc.c | 2 ++ 1 file changed, 2 insertions(+)
net/ipv6/ndisc.c +2 -0
@@ -1723,6 +1723,8 @@ static int ndisc_netdev_event(struct notifier_block *this, unsigned long event,case NETDEV_CHANGEADDR :neigh_changeaddr (&nd_tbl, dev);fib6_run_gc (0 , net, false); +/* fallthrough */ +case NETDEV_UP : idev =in6_dev_get (dev);if (!idev)break ;
Signature · 1 line
2.14.1
PATCH 39/190 media/dvb-core: Race condition when writing to CAM
In reply to Sasha LevinFrom: Jasmin J <[email protected]>
[ Upstream commit e7080d4471d805d921a9ea21b32f911a91e248cb ]
It started with a sporadic message in syslog: "CAM tried to send a buffer larger than the ecount size" This message is not the fault itself, but a consecutive fault, after a read error from the CAM. This happens only on several CAMs, several hardware, and of course sporadic.
It is a consecutive fault, if the last read from the CAM did fail. I guess this will not happen on all CAMs, but at least it did on mine. There was a write error to the CAM and during the re-initialization procedure, the CAM finished the last read, although it got a RS.
The write error to the CAM happened because a race condition between HC write, checking DA and FR.
This patch added an additional check for DA(RE), just after checking FR. It is important to read the CAMs status register again, to give the CAM the necessary time for a proper reaction to HC. Please note the description within the source code (patch below).
[[email protected]: make checkpatch happy]
--- drivers/media/dvb-core/dvb_ca_en50221.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)
drivers/media/dvb-core/dvb_ca_en50221.c +23 -0
@@ -779,6 +779,29 @@ static int dvb_ca_en50221_write_data(struct dvb_ca_private *ca, int slot, u8 * b goto exit; } +/* +* It may need some time for the CAM to settle down, or there might +* be a race condition between the CAM, writing HC and our last +* check for DA. This happens, if the CAM asserts DA, just after +* checking DA before we are setting HC. In this case it might be +* a bug in the CAM to keep the FR bit, the lower layer/HW +* communication requires a longer timeout or the CAM needs more +* time internally. But this happens in reality! +* We need to read the status from the HW again and do the same +* we did for the previous check for DA +*/ + status = ca->pub->read_cam_control (ca->pub, slot,CTRLIF_STATUS ); +if (status <0 ) + goto exit; + +if (status & (STATUSREG_DA |STATUSREG_RE )) { +if (status &STATUSREG_DA ) +dvb_ca_en50221_thread_wakeup (ca); + + status = -EAGAIN ; + goto exit; + } +/* send the amount of data */ if ((status = ca->pub->write_cam_control (ca->pub, slot,CTRLIF_SIZE_HIGH , bytes_write >>8 )) !=0 ) goto exit;
Signature · 1 line
2.14.1
PATCH 40/190 btrfs: fix a bogus warning when converting only data or metadata
In reply to Sasha LevinFrom: Adam Borowski <[email protected]>
[ Upstream commit 14506127979a5a3d0c5d9b4cc76ce9d4ec23b717 ]
If your filesystem has, eg, data:raid0 metadata:raid1, and you run "btrfs balance -dconvert=raid1", the meta.target field will be uninitialized. That's otherwise ok, as it's unused except for this warning.
Thus, let's use the existing set of raid levels for the comparison.
As a side effect, non-convert balances will now nag about data>metadata.
--- fs/btrfs/volumes.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
fs/btrfs/volumes.c +9 -3
@@ -3764,6 +3764,7 @@ int btrfs_balance(struct btrfs_balance_control *bctl, struct btrfs_ioctl_balance_args *bargs) {struct btrfs_fs_info *fs_info = bctl->fs_info; +u64 meta_target, data_target;u64 allowed;int mixed =0 ;int ret;
@@ -3860,11 +3861,16 @@ int btrfs_balance(struct btrfs_balance_control *bctl, } }while (read_seqretry (&fs_info->profiles_lock, seq)); -if (btrfs_get_num_tolerated_disk_barrier_failures (bctl->meta.target) < -btrfs_get_num_tolerated_disk_barrier_failures (bctl->data.target)) { +/* if we're not converting, the target field is uninitialized */ + meta_target = (bctl->meta.flags &BTRFS_BALANCE_ARGS_CONVERT ) ? + bctl->meta.target : fs_info->avail_metadata_alloc_bits; + data_target = (bctl->data.flags &BTRFS_BALANCE_ARGS_CONVERT ) ? + bctl->data.target : fs_info->avail_data_alloc_bits; +if (btrfs_get_num_tolerated_disk_barrier_failures (meta_target) < +btrfs_get_num_tolerated_disk_barrier_failures (data_target)) {btrfs_warn (fs_info,"metadata profile 0x%llx has lower redundancy than data profile 0x%llx" , - bctl->meta.target, bctl->data.target); + meta_target, data_target); }if (bctl->sys.flags &BTRFS_BALANCE_ARGS_CONVERT ) {
Signature · 1 line
2.14.1
PATCH 41/190 ASoC: Intel: Atom: update Thinkpad 10 quirk
In reply to Sasha LevinFrom: Pierre-Louis Bossart <[email protected]>
[ Upstream commit beb5989a8c6c6867b4e873cca2a66d31f977368f ]
There are multiple skews of the same Lenovo audio hardware based on the Realtek RT5670 codec.
Manufacturer: LENOVO
Product Name: 20C1CTO1WW
Version: ThinkPad 10
Manufacturer: LENOVO
Product Name: 20C3001VHH Version: ThinkPad 10
Manufacturer: LENOVO
Product Name: 20C10024GE Version: ThinkPad Tablet B
Manufacturer: LENOVO
Product Name: 20359 Version: Lenovo Miix 2 10
For all these devices, the same quirk is used to force the machine driver to be based on RT5670 instead of RT5640 as indicated by the BIOS.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96691
--- sound/soc/intel/atom/sst/sst_acpi.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
sound/soc/intel/atom/sst/sst_acpi.c +15 -1
@@ -420,7 +420,21 @@ static const struct dmi_system_id byt_table[] = { .callback = byt_thinkpad10_quirk_cb, .matches = {DMI_MATCH (DMI_SYS_VENDOR ,"LENOVO" ), - DMI_MATCH(DMI_PRODUCT_NAME, "20C3001VHH"), + DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad 10"), + }, + }, + { + .callback = byt_thinkpad10_quirk_cb, + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"LENOVO" ), + DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad Tablet B"), + }, + }, + { + .callback = byt_thinkpad10_quirk_cb, + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"LENOVO" ), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo Miix 2 10"), }, }, { }
Signature · 1 line
2.14.1
PATCH 42/190 tools/testing/nvdimm: fix nfit_test shutdown crash
In reply to Sasha LevinFrom: Dan Williams <[email protected]>
[ Upstream commit 8b06b884cd98f7ec8b5028680b99fabfb7b3e192 ]
Keep the nfit_test instances alive until after nfit_test_teardown(), as we may be doing resource lookups until the final un-registrations have completed. This fixes crashes of the form.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: __release_resource+0x12/0x90 Call Trace: remove_resource+0x23/0x40 __wrap_remove_resource+0x29/0x30 [nfit_test_iomap] acpi_nfit_remove_resource+0xe/0x10 [nfit] devm_action_release+0xf/0x20 release_nodes+0x16d/0x2b0 devres_release_all+0x3c/0x60 device_release+0x21/0x90 kobject_release+0x6a/0x170 kobject_put+0x2f/0x60 put_device+0x17/0x20 platform_device_unregister+0x20/0x30 nfit_test_exit+0x36/0x960 [nfit_test]
--- tools/testing/nvdimm/test/nfit.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
tools/testing/nvdimm/test/nfit.c +9 -1
@@ -1908,6 +1908,7 @@ static __init int nfit_test_init(void)put_device (&pdev->dev); goto err_register; } +get_device (&pdev->dev); rc =dma_coerce_mask_and_coherent (&pdev->dev,DMA_BIT_MASK (64 ));if (rc)
@@ -1926,6 +1927,10 @@ static __init int nfit_test_init(void)if (instances[i])platform_device_unregister (&instances[i]->pdev);nfit_test_teardown (); +for (i =0 ; i <NUM_NFITS ; i++) +if (instances[i]) +put_device (&instances[i]->pdev.dev); +return rc; }
@@ -1933,10 +1938,13 @@ static __exit void nfit_test_exit(void) {int i; -platform_driver_unregister (&nfit_test_driver);for (i =0 ; i <NUM_NFITS ; i++)platform_device_unregister (&instances[i]->pdev); +platform_driver_unregister (&nfit_test_driver);nfit_test_teardown (); + +for (i =0 ; i <NUM_NFITS ; i++) +put_device (&instances[i]->pdev.dev);class_destroy (nfit_test_dimm); }
Signature · 1 line
2.14.1
PATCH 43/190 spi: dw: Disable clock after unregistering the host
In reply to Sasha LevinFrom: Marek Vasut <[email protected]>
[ Upstream commit 400c18e3dc86e04ef5afec9b86a8586ca629b9e9 ]
The dw_mmio driver disables the block clock before unregistering the host. The code unregistering the host may access the SPI block registers. If register access happens with block clock disabled, this may lead to a bus hang. Disable the clock after unregistering the host to prevent such situation.
This bug was observed on Altera Cyclone V SoC.
--- drivers/spi/spi-dw-mmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-dw-mmio.c +1 -1
@@ -115,8 +115,8 @@ static int dw_spi_mmio_remove(struct platform_device *pdev) {struct dw_spi_mmio *dwsmmio =platform_get_drvdata (pdev); -clk_disable_unprepare (dwsmmio->clk);dw_spi_remove_host (&dwsmmio->dws); +clk_disable_unprepare (dwsmmio->clk);return 0 ; }
Signature · 1 line
2.14.1
PATCH 44/190 powerpc/64s: Remove SAO feature from Power9 DD1
In reply to Sasha LevinFrom: Nicholas Piggin <[email protected]>
[ Upstream commit ca80d5d0a8175c9be04cfbce24180b8f5e0a744b ]
Power9 DD1 does not implement SAO. Although it's not widely used, its presence or absence is visible to user space via arch_validate_prot() so it's moderately important that we get the value right.
--- arch/powerpc/include/asm/cputable.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/powerpc/include/asm/cputable.h +2 -1
@@ -474,7 +474,8 @@ enum { CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \ CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_DAWR | \ CPU_FTR_ARCH_207S | CPU_FTR_TM_COMP | CPU_FTR_ARCH_300) -#define CPU_FTRS_POWER9_DD1 (CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD1) +#define CPU_FTRS_POWER9_DD1 ((CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD1) & \ + (~CPU_FTR_SAO))#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
Signature · 1 line
2.14.1
PATCH 45/190 ath: Fix updating radar flags for coutry code India
In reply to Sasha LevinFrom: Mohammed Shafi Shajakhan <[email protected]>
[ Upstream commit c0c345d4cacc6a1f39d4856f37dcf6e34f51a5e4 ]
As per latest regulatory update for India, channel 52, 56, 60, 64 is no longer restricted to DFS. Enabling DFS/no infra flags in driver results in applying all DFS related restrictions (like doing CAC etc before this channel moves to 'available state') for these channels even though the country code is programmed as 'India' in he hardware, fix this by relaxing the frequency range while applying RADAR flags only if the country code is programmed to India. If the frequency range needs to modified based on different country code, ath_is_radar_freq can be extended/modified dynamically.
--- drivers/net/wireless/ath/regd.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)
drivers/net/wireless/ath/regd.c +12 -7
@@ -254,8 +254,12 @@ bool ath_is_49ghz_allowed(u16 regdomain)EXPORT_SYMBOL (ath_is_49ghz_allowed);/* Frequency is one where radar detection is required */ -static bool ath_is_radar_freq (u16 center_freq) +static bool ath_is_radar_freq (u16 center_freq, +struct ath_regulatory *reg) + { +if (reg->country_code ==CTRY_INDIA ) +return (center_freq >=5500 && center_freq <=5700 );return (center_freq >=5260 && center_freq <=5700 ); }
@@ -306,7 +310,7 @@ __ath_reg_apply_beaconing_flags(struct wiphy *wiphy, enum nl80211_reg_initiator initiator, struct ieee80211_channel *ch) { - if (ath_is_radar_freq(ch->center_freq) || + if (ath_is_radar_freq(ch->center_freq, reg) || (ch->flags & IEEE80211_CHAN_RADAR)) return;
@@ -395,8 +399,9 @@ ath_reg_apply_ir_flags(struct wiphy *wiphy, } } -/* Always apply Radar/DFS rules on freq range 5260 MHz - 5700 MHz */ -static void ath_reg_apply_radar_flags (struct wiphy *wiphy) +/* Always apply Radar/DFS rules on freq range 5500 MHz - 5700 MHz */ +static void ath_reg_apply_radar_flags (struct wiphy *wiphy, +struct ath_regulatory *reg) {struct ieee80211_supported_band *sband;struct ieee80211_channel *ch;
@@ -409,7 +414,7 @@ static void ath_reg_apply_radar_flags(struct wiphy *wiphy)for (i =0 ; i < sband->n_channels; i++) { ch = &sband->channels[i]; -if (!ath_is_radar_freq (ch->center_freq)) +if (!ath_is_radar_freq (ch->center_freq, reg))continue ;/* We always enable radar detection/DFS on this * frequency range. Additionally we also apply on
@@ -505,7 +510,7 @@ void ath_reg_notifier_apply(struct wiphy *wiphy, struct ath_common *common = container_of(reg, struct ath_common, regulatory);/* We always apply this */ -ath_reg_apply_radar_flags (wiphy); +ath_reg_apply_radar_flags (wiphy, reg);/* * This would happen when we have sent a custom regulatory request
@@ -653,7 +658,7 @@ ath_regd_init_wiphy(struct ath_regulatory *reg, }wiphy_apply_custom_regulatory (wiphy, regd); -ath_reg_apply_radar_flags (wiphy); +ath_reg_apply_radar_flags (wiphy, reg);ath_reg_apply_world_flags (wiphy,NL80211_REGDOM_SET_BY_DRIVER , reg);return 0 ; }
Signature · 1 line
2.14.1
PATCH 46/190 clk: ns2: Correct SDIO bits
In reply to Sasha LevinFrom: Bharat Kumar Reddy Gooty <[email protected]>
[ Upstream commit 8973aa4aecac223548366ca81818309a0f0efa6d ]
Corrected the bits for power and iso.
--- drivers/clk/bcm/clk-ns2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/bcm/clk-ns2.c +1 -1
@@ -103,7 +103,7 @@ CLK_OF_DECLARE(ns2_genpll_src_clk, "brcm,ns2-genpll-scr",static const struct iproc_pll_ctrl genpll_sw = { .flags =IPROC_CLK_AON |IPROC_CLK_PLL_SPLIT_STAT_CTRL , - .aon =AON_VAL (0x0 ,2 ,9 ,8 ), + .aon =AON_VAL (0x0 ,1 ,11 ,10 ), .reset =RESET_VAL (0x4 ,2 ,1 ), .dig_filter =DF_VAL (0x0 ,9 ,3 ,5 ,4 ,2 ,3 ), .ndiv_int =REG_VAL (0x8 ,4 ,10 ),
Signature · 1 line
2.14.1
PATCH 47/190 iwlwifi: split the handler and the wake parts of the notification infra
In reply to Sasha LevinFrom: Emmanuel Grumbach <[email protected]>
[ Upstream commit 2220fb2960b72915e7fd9da640a4695dceff238c ]
The notification infrastructure (iwl_notification_wait_* functions) allows to wait until a list of notifications will come up from the firmware and to run a special handler (notif_wait handler) when those are received.
The operation mode notifies the notification infrastructure about any Rx being received by the mean of iwl_notification_wait_notify() which will do two things:
1) call the notif_wait handler
2) wakeup the thread that was waiting for the notification
Typically, only after those two steps happened, the operation mode will run its own handler for the notification that was received from the firmware. This means that the thread that was waiting for that notification can be running before the operation mode's handler was called.
When the operation mode's handler is ASYNC, things get even worse since the thread that was waiting for the notification isn't even guaranteed that the ASYNC callback was added to async_handlers_list before it starts to run. This means that even calling iwl_mvm_wait_for_async_handlers() can't guarantee that absolutely everything related to that notification has run. The following can happen:
Thread sending the command Operation mode's Rx path
-------------------------- ------------------------iwl_init_notification_wait()iwl_mvm_send_cmd()
iwl_mvm_rx_common()
iwl_notification_wait_notify()
iwl_mvm_wait_for_async_handlers()
// Possibly free some data
// structure
list_add_tail(async_handlers_list);
schedule_work(async_handlers_wk);
// Access the freed structureSplit the 'run notif_wait's handler' and the 'wake up the thread' parts to fix this. This allows the operation mode to do the following:
Thread sending the command Operation mode's Rx path
-------------------------- ------------------------iwl_init_notification_wait()iwl_mvm_send_cmd()
iwl_mvm_rx_common()
iwl_notification_wait()
// Will run the notif_wait's handler
list_add_tail(async_handlers_list);
schedule_work(async_handlers_wk);
iwl_notification_notify()iwl_mvm_wait_for_async_handlers()
This way, the waiter is guaranteed that all the handlers have been run (if SYNC), or at least enqueued (if ASYNC) by the time it wakes up.
--- .../net/wireless/intel/iwlwifi/iwl-notif-wait.c | 10 ++++----- .../net/wireless/intel/iwlwifi/iwl-notif-wait.h | 25 +++++++++++++++++----- 2 files changed, 24 insertions(+), 11 deletions(-)
drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.c +4 -6
@@ -76,8 +76,8 @@ void iwl_notification_wait_init(struct iwl_notif_wait_data *notif_wait) }IWL_EXPORT_SYMBOL (iwl_notification_wait_init); -void iwl_notification_wait_notify (struct iwl_notif_wait_data *notif_wait, -struct iwl_rx_packet *pkt) +bool iwl_notification_wait (struct iwl_notif_wait_data *notif_wait, +struct iwl_rx_packet *pkt) {bool triggered = false;
@@ -118,13 +118,11 @@ void iwl_notification_wait_notify(struct iwl_notif_wait_data *notif_wait, } }spin_unlock (¬if_wait->notif_wait_lock); - } -if (triggered) -wake_up_all (¬if_wait->notif_waitq); +return triggered; } -IWL_EXPORT_SYMBOL (iwl_notification_wait_notify); +IWL_EXPORT_SYMBOL (iwl_notification_wait);void iwl_abort_notification_waits (struct iwl_notif_wait_data *notif_wait) {
drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.h +20 -5
@@ -6,7 +6,7 @@* GPL LICENSE SUMMARY * * Copyright(c) 2007 - 2014 Intel Corporation. All rights reserved. -* Copyright(c) 2015 Intel Deutschland GmbH +* Copyright(c) 2015 - 2017 Intel Deutschland GmbH * * This program is free software; you can redistribute it and/or modify * it under the terms of version 2 of the GNU General Public License as
@@ -32,6 +32,7 @@* BSD LICENSE * * Copyright(c) 2005 - 2014 Intel Corporation. All rights reserved. +* Copyright(c) 2015 - 2017 Intel Deutschland GmbH * All rights reserved. * * Redistribution and use in source and binary forms, with or without
@@ -89,10 +90,10 @@ struct iwl_notif_wait_data {* * This structure is not used directly, to wait for a * notification declare it on the stack, and call -* iwlagn_init_notification_wait() with appropriate +* iwl_init_notification_wait() with appropriate * parameters. Then do whatever will cause the ucode * to notify the driver, and to wait for that then -* call iwlagn_wait_notification(). +* call iwl_wait_notification(). * * Each notification is one-shot. If at some point we * need to support multi-shot notifications (which
@@ -114,10 +115,24 @@ struct iwl_notification_wait {/* caller functions */ void iwl_notification_wait_init (struct iwl_notif_wait_data *notif_data); -void iwl_notification_wait_notify (struct iwl_notif_wait_data *notif_data, -struct iwl_rx_packet *pkt); +bool iwl_notification_wait (struct iwl_notif_wait_data *notif_data, +struct iwl_rx_packet *pkt);void iwl_abort_notification_waits (struct iwl_notif_wait_data *notif_data); +static inline void +iwl_notification_notify (struct iwl_notif_wait_data *notif_data) +{ +wake_up_all (¬if_data->notif_waitq); +} + +static inline void +iwl_notification_wait_notify (struct iwl_notif_wait_data *notif_data, +struct iwl_rx_packet *pkt) +{ +if (iwl_notification_wait (notif_data, pkt)) +iwl_notification_notify (notif_data); +} +/* user functions */ void __acquires(wait_entry) iwl_init_notification_wait(struct iwl_notif_wait_data *notif_data,
Signature · 1 line
2.14.1
PATCH 48/190 iwlwifi: a000: fix memory offsets and lengths
In reply to Sasha LevinFrom: Liad Kaufman <[email protected]>
[ Upstream commit f4d1047914ea05e0f8393944da18f6ee5dad24c4 ]
Memory offsets and lengths for A000 HW is different than currently specified.
--- drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/wireless/intel/iwlwifi/iwl-a000.c +3 -3
@@ -65,12 +65,12 @@#define IWL_A000_TX_POWER_VERSION 0xffff/* meaningless */ /* Memory offsets and lengths */ -#define IWL_A000_DCCM_OFFSET 0x800000 -#define IWL_A000_DCCM_LEN 0x18000 +#define IWL_A000_DCCM_OFFSET 0x800000/* LMAC1 */ +#define IWL_A000_DCCM_LEN 0x10000/* LMAC1 */ #define IWL_A000_DCCM2_OFFSET 0x880000#define IWL_A000_DCCM2_LEN 0x8000#define IWL_A000_SMEM_OFFSET 0x400000 -#define IWL_A000_SMEM_LEN 0x68000 +#define IWL_A000_SMEM_LEN 0xD0000#define IWL_A000_FW_PRE "iwlwifi-Qu-a0-jf-b0-"#define IWL_A000_MODULE_FIRMWARE (api) \
Signature · 1 line
2.14.1
PATCH 49/190 scsi: virtio_scsi: Always try to read VPD pages
In reply to Sasha LevinFrom: David Gibson <[email protected]>
[ Upstream commit 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0 ]
Passed through SCSI targets may have transfer limits which come from the host SCSI controller or something on the host side other than the target itself.
To make this work properly, the hypervisor can adjust the target's VPD information to advertise these limits. But for that to work, the guest has to look at the VPD pages, which we won't do by default if it is an SPC-2 device, even if it does actually support it.
This adds a workaround to address this, forcing devices attached to a virtio-scsi controller to always check the VPD pages. This is modelled on a similar workaround for the storvsc (Hyper-V) SCSI controller, although that exists for slightly different reasons.
A specific case which causes this is a volume from IBM's IPR RAID controller (which presents as an SPC-2 device, although it does support VPD) passed through with qemu's 'scsi-block' device.
[mkp: fixed typo]
--- drivers/scsi/virtio_scsi.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
drivers/scsi/virtio_scsi.c +24 -0
@@ -28,6 +28,7 @@#include <scsi/scsi_device.h> #include <scsi/scsi_cmnd.h> #include <scsi/scsi_tcq.h> +#include <scsi/scsi_devinfo.h> #include <linux/seqlock.h> #define VIRTIO_SCSI_MEMPOOL_SZ 64
@@ -705,6 +706,28 @@ static int virtscsi_device_reset(struct scsi_cmnd *sc)return virtscsi_tmf (vscsi, cmd); } +static int virtscsi_device_alloc (struct scsi_device *sdevice) +{ +/* +* Passed through SCSI targets (e.g. with qemu's 'scsi-block') +* may have transfer limits which come from the host SCSI +* controller or something on the host side other than the +* target itself. +* +* To make this work properly, the hypervisor can adjust the +* target's VPD information to advertise these limits. But +* for that to work, the guest has to look at the VPD pages, +* which we won't do by default if it is an SPC-2 device, even +* if it does actually support it. +* +* So, set the blist to always try to read the VPD pages. +*/ + sdevice->sdev_bflags =BLIST_TRY_VPD_PAGES ; + +return 0 ; +} + +/** * virtscsi_change_queue_depth() - Change a virtscsi target's queue depth * @sdev: Virtscsi target whose queue depth to change
@@ -776,6 +799,7 @@ static struct scsi_host_template virtscsi_host_template_single = { .change_queue_depth = virtscsi_change_queue_depth, .eh_abort_handler = virtscsi_abort, .eh_device_reset_handler = virtscsi_device_reset, + .slave_alloc = virtscsi_device_alloc, .can_queue = 1024, .dma_boundary = UINT_MAX,
Signature · 1 line
2.14.1
PATCH 50/190 KVM: PPC: Book3S PR: Exit KVM on failed mapping
In reply to Sasha LevinFrom: Alexey Kardashevskiy <[email protected]>
[ Upstream commit bd9166ffe624000140fc6b606b256df01fc0d060 ]
At the moment kvmppc_mmu_map_page() returns -1 if mmu_hash_ops.hpte_insert() fails for any reason so the page fault handler resumes the guest and it faults on the same address again.
This adds distinction to kvmppc_mmu_map_page() to return -EIO if mmu_hash_ops.hpte_insert() failed for a reason other than full pteg. At the moment only pSeries_lpar_hpte_insert() returns -2 if plpar_pte_enter() failed with a code other than H_PTEG_FULL. Other mmu_hash_ops.hpte_insert() instances can only fail with -1 "full pteg".
With this change, if PR KVM fails to update HPT, it can signal the userspace about this instead of returning to guest and having the very same page fault over and over again.
--- arch/powerpc/kvm/book3s_64_mmu_host.c | 5 ++++- arch/powerpc/kvm/book3s_pr.c | 6 +++++- 2 files changed, 9 insertions(+), 2 deletions(-)
arch/powerpc/kvm/book3s_64_mmu_host.c +4 -1
@@ -177,12 +177,15 @@ int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte, ret = mmu_hash_ops.hpte_insert (hpteg, vpn, hpaddr, rflags, vflags, hpsize, hpsize,MMU_SEGSIZE_256M ); -if (ret <0 ) { +if (ret ==-1 ) {/* If we couldn't map a primary PTE, try a secondary */ hash = ~hash; vflags ^=HPTE_V_SECONDARY ; attempt++; goto map_again; + }else if (ret <0 ) { + r = -EIO ; + goto out_unlock; }else {trace_kvm_book3s_64_mmu_map (rflags, hpteg, vpn, hpaddr, orig_pte);
arch/powerpc/kvm/book3s_pr.c +5 -1
@@ -627,7 +627,11 @@ int kvmppc_handle_pagefault(struct kvm_run *run, struct kvm_vcpu *vcpu,kvmppc_mmu_unmap_page (vcpu, &pte); }/* The guest's PTE is not mapped yet. Map on the host */ -kvmppc_mmu_map_page (vcpu, &pte, iswrite); +if (kvmppc_mmu_map_page (vcpu, &pte, iswrite) == -EIO ) { +/* Exit KVM if mapping failed */ + run->exit_reason =KVM_EXIT_INTERNAL_ERROR ; +return RESUME_HOST ; + }if (data) vcpu->stat.sp_storage++; else if (vcpu->arch.mmu.is_dcbz32(vcpu) &&
Signature · 1 line
2.14.1
PATCH 51/190 mwifiex: don't leak 'chan_stats' on reset
In reply to Sasha LevinFrom: Brian Norris <[email protected]>
[ Upstream commit fb9e67bee3ab7111513130c516ffe378d885c0d0 ]
'chan_stats' is (re)allocated in _mwifiex_fw_dpc() -> mwifiex_init_channel_scan_gap(), which is called whenever the device is initialized -- at probe or at reset.
But we only free it in we completely unregister the adapter, meaning we leak a copy of it during every reset.
Let's free it in the shutdown / removal paths instead (and in the error-handling path), to avoid the leak.
Ideally, we can eventually unify much of mwifiex_shutdown_sw() and mwifiex_remove_card() (way too much copy-and-paste) to reduce the burden on bugfixes like this. But that's work for tomorrow.
--- drivers/net/wireless/marvell/mwifiex/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/wireless/marvell/mwifiex/main.c +3 -1
@@ -146,7 +146,6 @@ static int mwifiex_unregister(struct mwifiex_adapter *adapter)kfree (adapter->regd); -vfree (adapter->chan_stats);kfree (adapter);return 0 ; }
@@ -636,6 +635,7 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context) goto done; err_add_intf: +vfree (adapter->chan_stats);wiphy_unregister (adapter->wiphy);wiphy_free (adapter->wiphy); err_init_fw:
@@ -1429,6 +1429,7 @@ mwifiex_shutdown_sw(struct mwifiex_adapter *adapter, struct semaphore *sem)mwifiex_del_virtual_intf (adapter->wiphy, &priv->wdev);rtnl_unlock (); } +vfree (adapter->chan_stats);up (sem); exit_sem_err:
@@ -1729,6 +1730,7 @@ int mwifiex_remove_card(struct mwifiex_adapter *adapter, struct semaphore *sem)mwifiex_del_virtual_intf (adapter->wiphy, &priv->wdev);rtnl_unlock (); } +vfree (adapter->chan_stats);wiphy_unregister (adapter->wiphy);wiphy_free (adapter->wiphy);
Signature · 1 line
2.14.1
PATCH 52/190 x86/reboot: Turn off KVM when halting a CPU
In reply to Sasha LevinFrom: Tiantian Feng <[email protected]>
[ Upstream commit fba4f472b33aa81ca1836f57d005455261e9126f ]
A CPU in VMX root mode will ignore INIT signals and will fail to bring up the APs after reboot. Therefore, on a panic we disable VMX on all CPUs before rebooting or triggering kdump.
Do this when halting the machine as well, in case a firmware-level reboot does not perform a cold reset for all processors. Without doing this, rebooting the host may hang.
--- arch/x86/kernel/smp.c | 3 +++ 1 file changed, 3 insertions(+)
arch/x86/kernel/smp.c +3 -0
@@ -33,6 +33,7 @@#include <asm/mce.h> #include <asm/trace/irq_vectors.h> #include <asm/kexec.h> +#include <asm/virtext.h> /* * Some notes on x86 processor bugs affecting SMP operation:
@@ -162,6 +163,7 @@ static int smp_stop_nmi_callback(unsigned int val, struct pt_regs *regs)if (raw_smp_processor_id () ==atomic_read (&stopping_cpu))return NMI_HANDLED ; +cpu_emergency_vmxoff ();stop_this_cpu (NULL );return NMI_HANDLED ;
@@ -174,6 +176,7 @@ static int smp_stop_nmi_callback(unsigned int val, struct pt_regs *regs) asmlinkage __visible void smp_reboot_interrupt(void) {ipi_entering_ack_irq (); +cpu_emergency_vmxoff ();stop_this_cpu (NULL );irq_exit (); }
Signature · 1 line
2.14.1
PATCH 53/190 ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER
In reply to Sasha LevinFrom: Abel Vesa <[email protected]>
[ Upstream commit 6f05d0761af612e04572ba4d65b4c0274a88444f ]
The support for dynamic ftrace with CONFIG_DEBUG_RODATA involves overriding the weak arch_ftrace_update_code() with a variant which makes the kernel text writable around the patching.
This override was however added under the CONFIG_OLD_MCOUNT ifdef, and CONFIG_OLD_MCOUNT is only enabled if frame pointers are enabled.
This leads to non-functional dynamic ftrace (ftrace triggers a WARN_ON()) when CONFIG_DEBUG_RODATA is enabled and CONFIG_FRAME_POINTER is not.
Move the override out of that ifdef and into the CONFIG_DYNAMIC_FTRACE ifdef where it belongs.
--- arch/arm/kernel/ftrace.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
arch/arm/kernel/ftrace.c +6 -5
@@ -29,11 +29,6 @@#endif #ifdef CONFIG_DYNAMIC_FTRACE -#ifdef CONFIG_OLD_MCOUNT -#define OLD_MCOUNT_ADDR ((unsigned long) mcount) -#define OLD_FTRACE_ADDR ((unsigned long) ftrace_caller_old) - -#define OLD_NOP 0xe1a00000 /* mov r0, r0 */static int __ftrace_modify_code (void *data) {
@@ -51,6 +46,12 @@ void arch_ftrace_update_code(int command)stop_machine (__ftrace_modify_code, &command,NULL ); } +#ifdef CONFIG_OLD_MCOUNT +#define OLD_MCOUNT_ADDR ((unsigned long) mcount) +#define OLD_FTRACE_ADDR ((unsigned long) ftrace_caller_old) + +#define OLD_NOP 0xe1a00000/* mov r0, r0 */ +static unsigned long ftrace_nop_replace (struct dyn_ftrace *rec) {return rec->arch.old_mcount ?OLD_NOP :NOP ;
Signature · 1 line
2.14.1
PATCH 54/190 irqchip/mips-gic: Separate IPI reservation & usage tracking
In reply to Sasha LevinFrom: Paul Burton <[email protected]>
[ Upstream commit f8dcd9e81797ae24acc44c84f0eb3b9e6cee9791 ]
Since commit 2af70a962070 ("irqchip/mips-gic: Add a IPI hierarchy domain") introduced the GIC IPI IRQ domain we have tracked both reservation of interrupts & their use with a single bitmap - ipi_resrv. If an interrupt is reserved for use as an IPI but not actually in use then the appropriate bit is set in ipi_resrv. If an interrupt is either not reserved for use as an IPI or has been allocated as one then the appropriate bit is clear in ipi_resrv.
Unfortunately this means that checking whether a bit is set in ipi_resrv to prevent IPI interrupts being allocated for use with a device is broken, because if the interrupt has been allocated as an IPI first then its bit will be clear.
Fix this by separating the tracking of IPI reservation & usage, introducing a separate ipi_available bitmap for the latter. This means that ipi_resrv will now always have bits set corresponding to all interrupts reserved for use as IPIs, whether or not they have been allocated yet, and therefore that checking it when allocating device interrupts works as expected.
--- drivers/irqchip/irq-mips-gic.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/irqchip/irq-mips-gic.c +7 -5
@@ -55,6 +55,7 @@ static unsigned int gic_cpu_pin;static unsigned int timer_cpu_pin;static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller;DECLARE_BITMAP (ipi_resrv,GIC_MAX_INTRS ); +DECLARE_BITMAP (ipi_available,GIC_MAX_INTRS );static void __gic_irq_dispatch (void );
@@ -746,17 +747,17 @@ static int gic_irq_domain_alloc(struct irq_domain *d, unsigned int virq,return gic_setup_dev_chip (d, virq, spec->hwirq); }else { - base_hwirq =find_first_bit (ipi_resrv, gic_shared_intrs); + base_hwirq =find_first_bit (ipi_available, gic_shared_intrs);if (base_hwirq == gic_shared_intrs) {return -ENOMEM ; }/* check that we have enough space */ for (i = base_hwirq; i < nr_irqs; i++) { -if (!test_bit (i, ipi_resrv)) +if (!test_bit (i, ipi_available))return -EBUSY ; } -bitmap_clear (ipi_resrv, base_hwirq, nr_irqs); +bitmap_clear (ipi_available, base_hwirq, nr_irqs);/* map the hwirq for each cpu consecutively */ i =0 ;
@@ -787,7 +788,7 @@ static int gic_irq_domain_alloc(struct irq_domain *d, unsigned int virq,return 0 ; error: -bitmap_set (ipi_resrv, base_hwirq, nr_irqs); +bitmap_set (ipi_available, base_hwirq, nr_irqs);return ret; }
@@ -802,7 +803,7 @@ void gic_irq_domain_free(struct irq_domain *d, unsigned int virq,return ; base_hwirq =GIC_HWIRQ_TO_SHARED (irqd_to_hwirq (data)); -bitmap_set (ipi_resrv, base_hwirq, nr_irqs); +bitmap_set (ipi_available, base_hwirq, nr_irqs); } int gic_irq_domain_match(struct irq_domain *d, struct device_node *node,
@@ -1066,6 +1067,7 @@ static void __init __gic_init(unsigned long gic_base_addr, 2 * gic_vpes); } +bitmap_copy (ipi_available, ipi_resrv,GIC_MAX_INTRS );gic_basic_init (); }
Signature · 1 line
2.14.1
PATCH 55/190 iommu/omap: Register driver before setting IOMMU ops
In reply to Sasha LevinFrom: Suman Anna <[email protected]>
[ Upstream commit abaa7e5b054aae567861628b74dbc7fbf8ed79e8 ]
Move the registration of the OMAP IOMMU platform driver before setting the IOMMU callbacks on the platform bus. This causes the IOMMU devices to be probed first before the .add_device() callback is invoked for all registered devices, and allows the iommu_group support to be added to the OMAP IOMMU driver.
While at this, also check for the return status from bus_set_iommu.
--- drivers/iommu/omap-iommu.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)
drivers/iommu/omap-iommu.c +18 -3
@@ -1299,6 +1299,7 @@ static int __init omap_iommu_init(void)const unsigned long flags =SLAB_HWCACHE_ALIGN ;size_t align =1 <<10 ;/* L2 pagetable alignement */ struct device_node *np; +int ret; np =of_find_matching_node (NULL , omap_iommu_of_match);if (!np)
@@ -1312,11 +1313,25 @@ static int __init omap_iommu_init(void)return -ENOMEM ; iopte_cachep = p; -bus_set_iommu (&platform_bus_type, &omap_iommu_ops); -omap_iommu_debugfs_init (); -return platform_driver_register (&omap_iommu_driver); + ret =platform_driver_register (&omap_iommu_driver); +if (ret) { +pr_err ("%s: failed to register driver\n" , __func__); + goto fail_driver; + } + + ret =bus_set_iommu (&platform_bus_type, &omap_iommu_ops); +if (ret) + goto fail_bus; + +return 0 ; + +fail_bus: +platform_driver_unregister (&omap_iommu_driver); +fail_driver: +kmem_cache_destroy (iopte_cachep); +return ret; }subsys_initcall (omap_iommu_init);/* must be ready before omap3isp is probed */
Signature · 1 line
2.14.1
PATCH 56/190 md/raid10: wait up frozen array in handle_write_completed
In reply to Sasha LevinFrom: Guoqing Jiang <[email protected]>
[ Upstream commit cf25ae78fc50010f66b9be945017796da34c434d ]
Since nr_queued is changed, we need to call wake_up here if the array is already frozen and waiting for condition "nr_pending == nr_queued + extra" to be true.
And commit 824e47daddbf ("RAID1: avoid unnecessary spin locks in I/O barrier code") which has already added the wake_up for raid1.
--- drivers/md/raid10.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/md/raid10.c +5 -0
@@ -2704,6 +2704,11 @@ static void handle_write_completed(struct r10conf *conf, struct r10bio *r10_bio)list_add (&r10_bio->retry_list, &conf->bio_end_io_list); conf->nr_queued++;spin_unlock_irq (&conf->device_lock); +/* +* In case freeze_array() is waiting for condition +* nr_pending == nr_queued + extra to be true. +*/ +wake_up (&conf->wait_barrier);md_wakeup_thread (conf->mddev->thread); }else { if (test_bit(R10BIO_WriteError,
Signature · 1 line
2.14.1
PATCH 57/190 NFS: Fix missing pg_cleanup after nfs_pageio_cond_complete()
In reply to Sasha LevinFrom: Benjamin Coddington <[email protected]>
[ Upstream commit 43b7d964ed30dbca5c83c90cb010985b429ec4f9 ]
Commit a7d42ddb3099727f58366fa006f850a219cce6c8 ("nfs: add mirroring support to pgio layer") moved pg_cleanup out of the path when there was non-sequental I/O that needed to be flushed. The result is that for layouts that have more than one layout segment per file, the pg_lseg is not cleared, so we can end up hitting the WARN_ON_ONCE(req_start >= seg_end) in pnfs_generic_pg_test since the pg_lseg will be pointing to that previously-flushed layout segment.
--- fs/nfs/pagelist.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/nfs/pagelist.c +4 -2
@@ -1262,8 +1262,10 @@ void nfs_pageio_cond_complete(struct nfs_pageio_descriptor *desc, pgoff_t index) mirror = &desc->pg_mirrors[midx];if (!list_empty (&mirror->pg_list)) { prev =nfs_list_entry (mirror->pg_list.prev); -if (index != prev->wb_index +1 ) -nfs_pageio_complete_mirror (desc, midx); +if (index != prev->wb_index +1 ) { +nfs_pageio_complete (desc); +break ; + } } } }
Signature · 1 line
2.14.1
PATCH 58/190 tcp: remove poll() flakes with FastOpen
In reply to Sasha LevinFrom: Eric Dumazet <[email protected]>
[ Upstream commit 0f9fa831aecfc297b7b45d4f046759bcefcf87f0 ]
When using TCP FastOpen for an active session, we send one wakeup event from tcp_finish_connect(), right before the data eventually contained in the received SYNACK is queued to sk->sk_receive_queue.
This means that depending on machine load or luck, poll() users might receive POLLOUT events instead of POLLIN|POLLOUT
To fix this, we need to move the call to sk->sk_state_change() after the (optional) call to tcp_rcv_fastopen_synack()
--- net/ipv4/tcp_input.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
net/ipv4/tcp_input.c +9 -7
@@ -5606,10 +5606,6 @@ void tcp_finish_connect(struct sock *sk, struct sk_buff *skb)else tp->pred_flags =0 ; -if (!sock_flag (sk,SOCK_DEAD )) { - sk->sk_state_change (sk); -sk_wake_async (sk,SOCK_WAKE_IO ,POLL_OUT ); - } } static bool tcp_rcv_fastopen_synack(struct sock *sk, struct sk_buff *synack,
@@ -5678,6 +5674,7 @@ static int tcp_rcv_synsent_state_process(struct sock *sk, struct sk_buff *skb,struct tcp_sock *tp =tcp_sk (sk);struct tcp_fastopen_cookie foc = { .len =-1 };int saved_clamp = tp->rx_opt.mss_clamp; +bool fastopen_fail;tcp_parse_options (skb, &tp->rx_opt,0 , &foc);if (tp->rx_opt.saw_tstamp && tp->rx_opt.rcv_tsecr)
@@ -5781,10 +5778,15 @@ static int tcp_rcv_synsent_state_process(struct sock *sk, struct sk_buff *skb,tcp_finish_connect (sk, skb); -if ((tp->syn_fastopen || tp->syn_data) && -tcp_rcv_fastopen_synack (sk, skb, &foc)) -return -1 ; + fastopen_fail = (tp->syn_fastopen || tp->syn_data) && +tcp_rcv_fastopen_synack (sk, skb, &foc); +if (!sock_flag (sk,SOCK_DEAD )) { + sk->sk_state_change (sk); +sk_wake_async (sk,SOCK_WAKE_IO ,POLL_OUT ); + } +if (fastopen_fail) +return -1 ;if (sk->sk_write_pending || icsk->icsk_accept_queue.rskq_defer_accept || icsk->icsk_ack.pingpong) {
Signature · 1 line
2.14.1
PATCH 59/190 e1000e: fix timing for 82579 Gigabit Ethernet controller
In reply to Sasha LevinFrom: Bernd Faust <[email protected]>
[ Upstream commit 5313eeccd2d7f486be4e5c7560e3e2be239ec8f7 ]
After an upgrade to Linux kernel v4.x the hardware timestamps of the 82579 Gigabit Ethernet Controller are different than expected. The values that are being read are almost four times as big as before the kernel upgrade.
The difference is that after the upgrade the driver sets the clock frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel confirmed that the correct frequency for this network adapter is 96MHz.
--- drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/net/ethernet/intel/e1000e/netdev.c +6 -0
@@ -3528,6 +3528,12 @@ s32 e1000e_get_base_timinca(struct e1000_adapter *adapter, u32 *timinca)switch (hw->mac.type) {case e1000_pch2lan: +/* Stable 96MHz frequency */ + incperiod = INCPERIOD_96MHz; + incvalue = INCVALUE_96MHz; + shift = INCVALUE_SHIFT_96MHz; + adapter->cc.shift = shift + INCPERIOD_SHIFT_96MHz; +break ;case e1000_pch_lpt:if (er32 (TSYNCRXCTL ) &E1000_TSYNCRXCTL_SYSCFI ) {/* Stable 96MHz frequency */
Signature · 1 line
2.14.1
PATCH 60/190 ALSA: hda - Fix headset microphone detection for ASUS N551 and N751
In reply to Sasha LevinFrom: Mikhail Paulyshka <[email protected]>
[ Upstream commit fc7438b1eb12b6c93d7b7a62423779eb5dfc673c ]
Headset microphone does not work out of the box on ASUS Nx51 laptops. This patch fixes it.
Patch tested on Asus N551 laptop. Asus N751 part is not tested, but according to [1] this laptop uses the same audiosystem.
1. https://bugzilla.kernel.org/show_bug.cgi?id=117781
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195437
--- sound/pci/hda/patch_realtek.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
sound/pci/hda/patch_realtek.c +10 -2
@@ -6761,6 +6761,7 @@ enum {ALC668_FIXUP_DELL_DISABLE_AAMIX ,ALC668_FIXUP_DELL_XPS13 , ALC662_FIXUP_ASUS_Nx50, + ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, ALC668_FIXUP_ASUS_Nx51,ALC891_FIXUP_HEADSET_MODE , ALC891_FIXUP_DELL_MIC_NO_PRESENCE,
@@ -7012,14 +7013,21 @@ static const struct hda_fixup alc662_fixups[] = { .chained = true, .chain_id =ALC662_FIXUP_BASS_1A }, + [ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_headset_mode_alc668, + .chain_id =ALC662_FIXUP_BASS_CHMAP + }, [ALC668_FIXUP_ASUS_Nx51] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl []) { - {0x1a ,0x90170151 },/* bass speaker */ + {0x19 ,0x03a1913d },/* use as headphone mic, without its own jack detect */ + {0x1a ,0x90170151 },/* bass speaker */ + {0x1b ,0x03a1113c },/* use as headset mic, without its own jack detect */ {} }, .chained = true, - .chain_id = ALC662_FIXUP_BASS_CHMAP, + .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE, }, [ALC891_FIXUP_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC,
Signature · 1 line
2.14.1
PATCH 61/190 IB/ipoib: Fix deadlock between ipoib_stop and mcast join flow
In reply to Sasha LevinFrom: Feras Daoud <[email protected]>
[ Upstream commit 3e31a490e01a6e67cbe9f6e1df2f3ff0fbf48972 ]
Before calling ipoib_stop, rtnl_lock should be taken, then the flow clears the IPOIB_FLAG_ADMIN_UP and IPOIB_FLAG_OPER_UP flags, and waits for mcast completion if IPOIB_MCAST_FLAG_BUSY is set.
On the other hand, the flow of multicast join task initializes a mcast completion, sets the IPOIB_MCAST_FLAG_BUSY and calls ipoib_mcast_join. If IPOIB_FLAG_OPER_UP flag is not set, this call returns EINVAL without setting the mcast completion and leads to a deadlock.
ipoib_stop |
| |
clear_bit(IPOIB_FLAG_ADMIN_UP) |
| |
Context Switch |
| ipoib_mcast_join_task
| |
| spin_lock_irq(lock)
| |
| init_completion(mcast)
| |
| set_bit(IPOIB_MCAST_FLAG_BUSY)
| |
| Context Switch
| |
clear_bit(IPOIB_FLAG_OPER_UP) |
| |
spin_lock_irqsave(lock) |
| |
Context Switch |
| ipoib_mcast_join
| return (-EINVAL)
| |
| spin_unlock_irq(lock)
| |
| Context Switch
| | ipoib_mcast_dev_flush |
wait_for_completion(mcast) |
ipoib_stop will wait for mcast completion for ever, and will not release the rtnl_lock. As a result panic occurs with the following trace:
[13441.639268] Call Trace:
[13441.640150] [<ffffffff8168b579>] schedule+0x29/0x70
[13441.641038] [<ffffffff81688fc9>] schedule_timeout+0x239/0x2d0
[13441.641914] [<ffffffff810bc017>] ? complete+0x47/0x50
[13441.642765] [<ffffffff810a690d>] ? flush_workqueue_prep_pwqs+0x16d/0x200
[13441.643580] [<ffffffff8168b956>] wait_for_completion+0x116/0x170
[13441.644434] [<ffffffff810c4ec0>] ? wake_up_state+0x20/0x20
[13441.645293] [<ffffffffa05af170>] ipoib_mcast_dev_flush+0x150/0x190 [ib_ipoib]
[13441.646159] [<ffffffffa05ac967>] ipoib_ib_dev_down+0x37/0x60 [ib_ipoib]
[13441.647013] [<ffffffffa05a4805>] ipoib_stop+0x75/0x150 [ib_ipoib]--- drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
drivers/infiniband/ulp/ipoib/ipoib_multicast.c +5 -6
@@ -487,6 +487,9 @@ static int ipoib_mcast_join(struct net_device *dev, struct ipoib_mcast *mcast) !test_bit(IPOIB_FLAG_OPER_UP, &priv->flags))return -EINVAL ; +init_completion (&mcast->done); +set_bit (IPOIB_MCAST_FLAG_BUSY , &mcast->flags); +ipoib_dbg_mcast (priv,"joining MGID %pI6\n" , mcast->mcmember.mgid.raw); rec.mgid = mcast->mcmember.mgid;
@@ -645,8 +648,6 @@ void ipoib_mcast_join_task(struct work_struct *work)if (mcast->backoff ==1 ||time_after_eq (jiffies, mcast->delay_until)) {/* Found the next unjoined group */ -init_completion (&mcast->done); -set_bit (IPOIB_MCAST_FLAG_BUSY , &mcast->flags);if (ipoib_mcast_join (dev, mcast)) {spin_unlock_irq (&priv->lock);return ;
@@ -666,11 +667,9 @@ void ipoib_mcast_join_task(struct work_struct *work)queue_delayed_work (priv->wq, &priv->mcast_task, delay_until - jiffies); } -if (mcast) { -init_completion (&mcast->done); -set_bit (IPOIB_MCAST_FLAG_BUSY , &mcast->flags); +if (mcast)ipoib_mcast_join (dev, mcast); - } +spin_unlock_irq (&priv->lock); }
Signature · 1 line
2.14.1
PATCH 62/190 IB/ipoib: Update broadcast object if PKey value was changed in index 0
In reply to Sasha LevinFrom: Feras Daoud <[email protected]>
[ Upstream commit 9a9b8112699d78e7f317019b37f377e90023f3ed ]
Update the broadcast address in the priv->broadcast object when the Pkey value changes in index 0, otherwise the multicast GID value will keep the previous value of the PKey, and will not be updated. This leads to interface state down because the interface will keep the old PKey value.
For example, in SR-IOV environment, if the PF changes the value of PKey index 0 for one of the VFs, then the VF receives PKey change event that triggers heavy flush. This flush calls update_parent_pkey that update the broadcast object and its relevant members. If in this case the multicast GID will not be updated, the interface state will be down.
--- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
drivers/infiniband/ulp/ipoib/ipoib_ib.c +13 -0
@@ -974,6 +974,19 @@ static inline int update_parent_pkey(struct ipoib_dev_priv *priv)*/ priv->dev->broadcast[8 ] = priv->pkey >>8 ; priv->dev->broadcast[9 ] = priv->pkey &0xff ; + +/* +* Update the broadcast address in the priv->broadcast object, +* in case it already exists, otherwise no one will do that. +*/ +if (priv->broadcast) { +spin_lock_irq (&priv->lock); +memcpy (priv->broadcast->mcmember.mgid.raw, + priv->dev->broadcast +4 , +sizeof (union ib_gid )); +spin_unlock_irq (&priv->lock); + } +return 0 ; }
Signature · 1 line
2.14.1
PATCH 63/190 HSI: ssi_protocol: double free in ssip_pn_xmit()
In reply to Sasha LevinFrom: Dan Carpenter <[email protected]>
[ Upstream commit 3026050179a3a9a6f5c892c414b5e36ecf092081 ]
If skb_pad() fails then it frees skb and we don't need to free it again at the end of the function.
--- drivers/hsi/clients/ssi_protocol.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/hsi/clients/ssi_protocol.c +3 -2
@@ -989,7 +989,7 @@ static int ssip_pn_xmit(struct sk_buff *skb, struct net_device *dev) goto drop;/* Pad to 32-bits - FIXME: Revisit*/ if ((skb->len &3 ) &&skb_pad (skb,4 - (skb->len &3 ))) - goto drop; + goto inc_dropped;/* * Modem sends Phonet messages over SSI with its own endianess...
@@ -1041,8 +1041,9 @@ static int ssip_pn_xmit(struct sk_buff *skb, struct net_device *dev) drop2:hsi_free_msg (msg); drop: - dev->stats.tx_dropped++;dev_kfree_skb (skb); +inc_dropped: + dev->stats.tx_dropped++;return 0 ; }
Signature · 1 line
2.14.1
PATCH 64/190 IB/mlx4: Take write semaphore when changing the vma struct
In reply to Sasha LevinFrom: Maor Gottlieb <[email protected]>
[ Upstream commit 22c3653d04bd0c67b75e99d85e0c0bdf83947df5 ]
When the driver disassociate user context, it changes the vma to anonymous by setting the vm_ops to null and zap the vma ptes.
In order to avoid race in the kernel, we need to take write lock before we change the vma entries.
--- drivers/infiniband/hw/mlx4/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/infiniband/hw/mlx4/main.c +2 -2
@@ -1168,7 +1168,7 @@ static void mlx4_ib_disassociate_ucontext(struct ib_ucontext *ibcontext)/* need to protect from a race on closing the vma as part of * mlx4_ib_vma_close(). */ -down_read (&owning_mm->mmap_sem); +down_write (&owning_mm->mmap_sem);for (i =0 ; i <HW_BAR_COUNT ; i++) { vma = context->hw_bar_info[i].vma;if (!vma)
@@ -1186,7 +1186,7 @@ static void mlx4_ib_disassociate_ucontext(struct ib_ucontext *ibcontext) context->hw_bar_info[i].vma->vm_ops =NULL ; } -up_read (&owning_mm->mmap_sem); +up_write (&owning_mm->mmap_sem);mmput (owning_mm);put_task_struct (owning_process); }
Signature · 1 line
2.14.1
PATCH 65/190 IB/mlx4: Change vma from shared to private
In reply to Sasha LevinFrom: Maor Gottlieb <[email protected]>
[ Upstream commit ca37a664a8e4e9988b220988ceb4d79e3316f195 ]
Anonymous VMA (->vm_ops == NULL) cannot be shared, otherwise it would lead to SIGBUS.
Remove the shared flags from the vma after we change it to be anonymous.
This is easily reproduced by doing modprobe -r while running a user-space application such as raw_ethernet_bw.
--- drivers/infiniband/hw/mlx4/main.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/infiniband/hw/mlx4/main.c +2 -0
@@ -1182,6 +1182,8 @@ static void mlx4_ib_disassociate_ucontext(struct ib_ucontext *ibcontext)BUG_ON (1 ); } + context->hw_bar_info[i].vma->vm_flags &= + ~(VM_SHARED |VM_MAYSHARE );/* context going to be destroyed, should not access ops any more */ context->hw_bar_info[i].vma->vm_ops =NULL ; }
Signature · 1 line
2.14.1
PATCH 66/190 IB/mlx5: Take write semaphore when changing the vma struct
In reply to Sasha LevinFrom: Maor Gottlieb <[email protected]>
[ Upstream commit ecc7d83be3243835c9396a1a2fb8ce95f205207b ]
When the driver disassociate user context, it changes the vma to anonymous by setting the vm_ops to null and zap the vma ptes.
In order to avoid race in the kernel, we need to take write lock before we change the vma entries.
--- drivers/infiniband/hw/mlx5/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/infiniband/hw/mlx5/main.c +2 -2
@@ -1313,7 +1313,7 @@ static void mlx5_ib_disassociate_ucontext(struct ib_ucontext *ibcontext)/* need to protect from a race on closing the vma as part of * mlx5_ib_vma_close. */ -down_read (&owning_mm->mmap_sem); +down_write (&owning_mm->mmap_sem);list_for_each_entry_safe (vma_private, n, &context->vma_private_list, list) { vma = vma_private->vma;
@@ -1327,7 +1327,7 @@ static void mlx5_ib_disassociate_ucontext(struct ib_ucontext *ibcontext)list_del (&vma_private->list);kfree (vma_private); } -up_read (&owning_mm->mmap_sem); +up_write (&owning_mm->mmap_sem);mmput (owning_mm);put_task_struct (owning_process); }
Signature · 1 line
2.14.1
PATCH 67/190 IB/mlx5: Change vma from shared to private
In reply to Sasha LevinFrom: Maor Gottlieb <[email protected]>
[ Upstream commit 1377661298d2820d675553d186c31b6f46c140d0 ]
Anonymous VMA (->vm_ops == NULL) cannot be shared, otherwise it would lead to SIGBUS.
Remove the shared flags from the vma after we change it to be anonymous.
This is easily reproduced by doing modprobe -r while running a user-space application such as raw_ethernet_bw.
--- drivers/infiniband/hw/mlx5/main.c | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/hw/mlx5/main.c +1 -0
@@ -1323,6 +1323,7 @@ static void mlx5_ib_disassociate_ucontext(struct ib_ucontext *ibcontext)/* context going to be destroyed, should * not access ops any more. */ + vma->vm_flags &= ~(VM_SHARED |VM_MAYSHARE ); vma->vm_ops =NULL ;list_del (&vma_private->list);kfree (vma_private);
Signature · 1 line
2.14.1
PATCH 68/190 IB/mlx5: Set correct SL in completion for RoCE
In reply to Sasha LevinFrom: Moni Shoua <[email protected]>
[ Upstream commit 12f8fedef2ec94c783f929126b20440a01512c14 ]
There is a difference when parsing a completion entry between Ethernet and IB ports. When link layer is Ethernet the bits describe the type of L3 header in the packet. In the case when link layer is Ethernet and VLAN header is present the value of SL is equal to the 3 UP bits in the VLAN header. If VLAN header is not present then the SL is undefined and consumer of the completion should check if IB_WC_WITH_VLAN is set.
While that, this patch also fills the vlan_id field in the completion if present.
--- drivers/infiniband/hw/mlx5/cq.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-)
drivers/infiniband/hw/mlx5/cq.c +16 -3
@@ -172,6 +172,8 @@ static void handle_responder(struct ib_wc *wc, struct mlx5_cqe64 *cqe,struct mlx5_ib_srq *srq;struct mlx5_ib_wq *wq;u16 wqe_ctr; +u8 roce_packet_type; +bool vlan_present;u8 g;if (qp->ibqp.srq || qp->ibqp.xrcd) {
@@ -223,7 +225,6 @@ static void handle_responder(struct ib_wc *wc, struct mlx5_cqe64 *cqe,break ; } wc->slid =be16_to_cpu (cqe->slid); - wc->sl = (be32_to_cpu (cqe->flags_rqpn) >>24 ) &0xf ; wc->src_qp =be32_to_cpu (cqe->flags_rqpn) &0xffffff ; wc->dlid_path_bits = cqe->ml_path; g = (be32_to_cpu (cqe->flags_rqpn) >>28 ) &3 ;
@@ -237,10 +238,22 @@ static void handle_responder(struct ib_wc *wc, struct mlx5_cqe64 *cqe, wc->pkey_index =0 ; } -if (ll !=IB_LINK_LAYER_ETHERNET ) +if (ll !=IB_LINK_LAYER_ETHERNET ) { + wc->sl = (be32_to_cpu (cqe->flags_rqpn) >>24 ) &0xf ;return ; + } + + vlan_present = cqe->l4_l3_hdr_type &0x1 ; + roce_packet_type = (be32_to_cpu (cqe->flags_rqpn) >>24 ) &0x3 ; +if (vlan_present) { + wc->vlan_id = (be16_to_cpu (cqe->vlan_info)) &0xfff ; + wc->sl = (be16_to_cpu (cqe->vlan_info) >>13 ) &0x7 ; + wc->wc_flags |=IB_WC_WITH_VLAN ; + }else { + wc->sl =0 ; + } -switch (wc->sl &0x3 ) { +switch (roce_packet_type) {case MLX5_CQE_ROCE_L3_HEADER_TYPE_GRH : wc->network_hdr_type =RDMA_NETWORK_IB ;break ;
Signature · 1 line
2.14.1
PATCH 69/190 ASoC: Intel: Skylake: Uninitialized variable in probe_codec()
In reply to Sasha LevinFrom: Dan Carpenter <[email protected]>
[ Upstream commit e6a33532affd14c12688c0e9b2e773e8b2550f3b ]
My static checker complains that if snd_hdac_bus_get_response() returns -EIO then "res" is uninitialized. Fix this by initializing it to -1 so that the error is handled correctly.
--- sound/soc/intel/skylake/skl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/intel/skylake/skl.c +1 -1
@@ -457,7 +457,7 @@ static int probe_codec(struct hdac_ext_bus *ebus, int addr)struct hdac_bus *bus =ebus_to_hbus (ebus);unsigned int cmd = (addr <<28 ) | (AC_NODE_ROOT <<20 ) | (AC_VERB_PARAMETERS <<8 ) |AC_PAR_VENDOR_ID ; -unsigned int res; +unsigned int res =-1 ;mutex_lock (&bus->cmd_mutex);snd_hdac_bus_send_cmd (bus, cmd);
Signature · 1 line
2.14.1
PATCH 70/190 ibmvnic: Disable irq prior to close
In reply to Sasha LevinFrom: Brian King <[email protected]>
[ Upstream commit dd9c20fa07ba5cfb5a0ab3181d68530506610605 ]
Add some code to call disable_irq on all the vnic interface's irqs.
This fixes a crash observed when closing an active interface, as
seen in the oops below when we try to access a buffer in the interrupt
handler which we've already freed.
Unable to handle kernel paging request for data at address 0x00000001
Faulting instruction address: 0xd000000003886824
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: ibmvnic(OEN) rpadlpar_io(X) rpaphp(X) tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag rpcsec_
Supported: No, Unsupported modules are loaded
CPU: 8 PID: 0 Comm: swapper/8 Tainted: G OE NX 4.4.49-92.11-default #1
task: c00000007f990110 ti: c0000000fffa0000 task.ti: c00000007f9b8000
NIP: d000000003886824 LR: d000000003886824 CTR: c0000000007eff60
REGS: c0000000fffa3a70 TRAP: 0300 Tainted: G OE NX (4.4.49-92.11-default)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22008042 XER: 20000008
CFAR: c000000000008468 DAR: 0000000000000001 DSISR: 40000000 SOFTE: 0
GPR00: d000000003886824 c0000000fffa3cf0 d000000003894118 0000000000000000
GPR04: 0000000000000000 0000000000000000 c000000001249da0 0000000000000000
GPR08: 000000000000000e 0000000000000000 c0000000ccb00000 d000000003889180
GPR12: c0000000007eff60 c000000007af4c00 0000000000000001 c0000000010def30
GPR16: c00000007f9b8000 c000000000b98c30 c00000007f9b8080 c000000000bab858
GPR20: 0000000000000005 0000000000000000 c0000000ff5d7e80 c0000000f809f648
GPR24: c0000000ff5d7ec8 0000000000000000 0000000000000000 c0000000ccb001a0
GPR28: 000000000000000a c0000000f809f600 c0000000fd4cd900 c0000000f9cd5b00
NIP [d000000003886824] ibmvnic_interrupt_tx+0x114/0x380 [ibmvnic]
LR [d000000003886824] ibmvnic_interrupt_tx+0x114/0x380 [ibmvnic]
Call Trace:
[c0000000fffa3cf0] [d000000003886824] ibmvnic_interrupt_tx+0x114/0x380 [ibmvnic] (unreliable)
[c0000000fffa3dd0] [c000000000132940] __handle_irq_event_percpu+0x90/0x2e0
[c0000000fffa3e90] [c000000000132bcc] handle_irq_event_percpu+0x3c/0x90
[c0000000fffa3ed0] [c000000000132c88] handle_irq_event+0x68/0xc0
[c0000000fffa3f00] [c000000000137edc] handle_fasteoi_irq+0xec/0x250
[c0000000fffa3f30] [c000000000131b04] generic_handle_irq+0x54/0x80
[c0000000fffa3f60] [c000000000011190] __do_irq+0x80/0x1d0
[c0000000fffa3f90] [c0000000000248d8] call_do_irq+0x14/0x24
[c00000007f9bb9e0] [c000000000011380] do_IRQ+0xa0/0x120
[c00000007f9bba40] [c000000000002594] hardware_interrupt_common+0x114/0x180--- drivers/net/ethernet/ibm/ibmvnic.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
drivers/net/ethernet/ibm/ibmvnic.c +18 -0
@@ -511,6 +511,23 @@ static int ibmvnic_open(struct net_device *netdev)return -ENOMEM ; } +static void disable_sub_crqs (struct ibmvnic_adapter *adapter) +{ +int i; + +if (adapter->tx_scrq) { +for (i =0 ; i < adapter->req_tx_queues; i++) +if (adapter->tx_scrq[i]) +disable_irq (adapter->tx_scrq[i]->irq); + } + +if (adapter->rx_scrq) { +for (i =0 ; i < adapter->req_rx_queues; i++) +if (adapter->rx_scrq[i]) +disable_irq (adapter->rx_scrq[i]->irq); + } +} +static int ibmvnic_close (struct net_device *netdev) {struct ibmvnic_adapter *adapter =netdev_priv (netdev);
@@ -519,6 +536,7 @@ static int ibmvnic_close(struct net_device *netdev)int i; adapter->closing = true; +disable_sub_crqs (adapter);for (i =0 ; i < adapter->req_rx_queues; i++)napi_disable (&adapter->napi[i]);
Signature · 1 line
2.14.1
PATCH 71/190 netvsc: Deal with rescinded channels correctly
In reply to Sasha LevinFrom: "K. Y. Srinivasan" <[email protected]>
[ Upstream commit 73e64fa4f417b22d8d5521999a631ced8e2d442e ]
We will not be able to send packets over a channel that has been rescinded. Make necessary adjustments so we can properly cleanup even when the channel is rescinded. This issue can be trigerred in the NIC hot-remove path.
--- drivers/net/hyperv/netvsc.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
drivers/net/hyperv/netvsc.c +16 -0
@@ -151,6 +151,13 @@ static void netvsc_destroy_buf(struct hv_device *device)sizeof (struct nvsp_message ), (unsigned long )revoke_packet, VM_PKT_DATA_INBAND, 0); +/* If the failure is because the channel is rescinded; +* ignore the failure since we cannot send on a rescinded +* channel. This would allow us to properly cleanup +* even when the channel is rescinded. +*/ +if (device->channel->rescind) + ret =0 ;/* * If we failed here, we might as well return and * have a leak rather than continue and a bugchk
@@ -211,6 +218,15 @@ static void netvsc_destroy_buf(struct hv_device *device)sizeof (struct nvsp_message ), (unsigned long )revoke_packet, VM_PKT_DATA_INBAND, 0); + +/* If the failure is because the channel is rescinded; +* ignore the failure since we cannot send on a rescinded +* channel. This would allow us to properly cleanup +* even when the channel is rescinded. +*/ +if (device->channel->rescind) + ret =0 ; +/* If we failed here, we might as well return and * have a leak rather than continue and a bugchk */
Signature · 1 line
2.14.1
PATCH 72/190 Fix driver usage of 128B WQEs when WQ_CREATE is V1.
In reply to Sasha LevinFrom: James Smart <[email protected]>
[ Upstream commit 3f247de750b8dd8f50a2c1390e2a1238790a9dff ]
There are two versions of a structure for queue creation and setup that the driver shares with FW. The driver was only treating as version 0.
Verify WQ_CREATE with 128B WQEs in V0 and V1.
Code review of another bug showed the driver passing 128B WQEs and 8 pages in WQ CREATE and V0.
Code inspection/instrumentation showed that the driver uses V0 in WQ_CREATE and if the caller passes queue->entry_size 128B, the driver sets the hdr_version to V1 so all is good. When I tested the V1 WQ_CREATE, the mailbox failed causing the driver to unload.
--- drivers/scsi/lpfc/lpfc_sli.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/scsi/lpfc/lpfc_sli.c +3 -0
@@ -13696,6 +13696,9 @@ lpfc_wq_create(struct lpfc_hba *phba, struct lpfc_queue *wq,case LPFC_Q_CREATE_VERSION_1 :bf_set (lpfc_mbx_wq_create_wqe_count, &wq_create->u.request_1, wq->entry_count); +bf_set (lpfc_mbox_hdr_version, &shdr->request, +LPFC_Q_CREATE_VERSION_1 ); +switch (wq->entry_size) {default :case 64 :
Signature · 1 line
2.14.1
PATCH 73/190 Fix Express lane queue creation.
In reply to Sasha LevinFrom: James Smart <[email protected]>
[ Upstream commit 7e04e21afa82ef024416f5413b5bdb66e0505bcd ]
The older sli4 adapters only supported the 64 byte WQE entry size. The new adapter (fw) support both 64 and 128 byte WQE entry sizies. The Express lane WQ was not being created with the 128 byte WQE sizes when it was supported.
Not having the right WQE size created for the express lane work queue caused the the firmware to overwrite the lun indentifier in the FCP header.
This patch correctly creates the express lane work queue with the supported size.
--- drivers/scsi/lpfc/lpfc_init.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_init.c +5 -1
@@ -11312,6 +11312,7 @@ int lpfc_fof_queue_create(struct lpfc_hba *phba) {struct lpfc_queue *qdesc; +uint32_t wqesize;/* Create FOF EQ */ qdesc = lpfc_sli4_queue_alloc(phba, phba->sli4_hba.eq_esize,
@@ -11332,8 +11333,11 @@ lpfc_fof_queue_create(struct lpfc_hba *phba) phba->sli4_hba.oas_cq = qdesc;/* Create OAS WQ */ - qdesc =lpfc_sli4_queue_alloc (phba, phba->sli4_hba.wq_esize, + wqesize = (phba->fcp_embed_io) ? +LPFC_WQE128_SIZE : phba->sli4_hba.wq_esize; + qdesc =lpfc_sli4_queue_alloc (phba, wqesize, phba->sli4_hba.wq_ecount); +if (!qdesc) goto out_error;
Signature · 1 line
2.14.1
PATCH 74/190 gpio: gpio-wcove: fix irq pending status bit width
In reply to Sasha LevinFrom: Kuppuswamy Sathyanarayanan <[email protected]>
[ Upstream commit 7c2d176fe3f8dce632b948f79c7e89916ffe2c70 ]
Whiskey cove PMIC has three GPIO banks with total number of 13 GPIO pins. But when checking for the pending status, for_each_set_bit() uses bit width of 7 and hence it only checks the status for first 7 GPIO pins missing to check/clear the status of rest of the GPIO pins. This patch fixes this issue.
--- drivers/gpio/gpio-wcove.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpio-wcove.c +1 -1
@@ -318,7 +318,7 @@ static irqreturn_t wcove_gpio_irq_handler(int irq, void *data)while (pending) {/* One iteration is for all pending bits */ for_each_set_bit (gpio, (const unsigned long *)&pending, -GROUP0_NR_IRQS ) { +WCOVE_GPIO_NUM ) { offset = (gpio >GROUP0_NR_IRQS ) ?1 :0 ; mask = (offset ==1 ) ?BIT (gpio -GROUP0_NR_IRQS ) :BIT (gpio);
Signature · 1 line
2.14.1
PATCH 75/190 netfilter: xt_CT: fix refcnt leak on error path
In reply to Sasha LevinFrom: Gao Feng <[email protected]>
[ Upstream commit 470acf55a021713869b9bcc967268ac90c8a0fac ]
There are two cases which causes refcnt leak.
1. When nf_ct_timeout_ext_add failed in xt_ct_set_timeout, it should free the timeout refcnt.
Now goto the err_put_timeout error handler instead of going ahead.
2. When the time policy is not found, we should call module_put. Otherwise, the related cthelper module cannot be removed anymore. It is easy to reproduce by typing the following command:
# iptables -t raw -A OUTPUT -p tcp -j CT --helper ftp --timeout xxx
--- net/netfilter/xt_CT.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
net/netfilter/xt_CT.c +9 -2
@@ -168,8 +168,10 @@ xt_ct_set_timeout(struct nf_conn *ct, const struct xt_tgchk_param *par, goto err_put_timeout; } timeout_ext =nf_ct_timeout_ext_add (ct, timeout,GFP_ATOMIC ); -if (timeout_ext ==NULL ) +if (!timeout_ext) { ret = -ENOMEM ; + goto err_put_timeout; + }rcu_read_unlock ();return ret;
@@ -201,6 +203,7 @@ static int xt_ct_tg_check(const struct xt_tgchk_param *par, struct xt_ct_target_info_v1 *info) {struct nf_conntrack_zone zone; +struct nf_conn_help *help;struct nf_conn *ct;int ret = -EOPNOTSUPP ;
@@ -249,7 +252,7 @@ static int xt_ct_tg_check(const struct xt_tgchk_param *par,if (info->timeout[0 ]) { ret =xt_ct_set_timeout (ct, par, info->timeout);if (ret <0 ) - goto err3; + goto err4; }__set_bit (IPS_CONFIRMED_BIT , &ct->status);nf_conntrack_get (&ct->ct_general);
@@ -257,6 +260,10 @@ static int xt_ct_tg_check(const struct xt_tgchk_param *par, info->ct = ct;return 0 ; +err4: + help =nfct_help (ct); +if (help) +module_put (help->helper->me); err3:nf_ct_tmpl_free (ct); err2:
Signature · 1 line
2.14.1
PATCH 76/190 openvswitch: Delete conntrack entry clashing with an expectation.
In reply to Sasha LevinFrom: Jarno Rajahalme <[email protected]>
[ Upstream commit cf5d70918877c6a6655dc1e92e2ebb661ce904fd ]
Conntrack helpers do not check for a potentially clashing conntrack entry when creating a new expectation. Also, nf_conntrack_in() will check expectations (via init_conntrack()) only if a conntrack entry can not be found. The expectation for a packet which also matches an existing conntrack entry will not be removed by conntrack, and is currently handled inconsistently by OVS, as OVS expects the expectation to be removed when the connection tracking entry matching that expectation is confirmed.
It should be noted that normally an IP stack would not allow reuse of a 5-tuple of an old (possibly lingering) connection for a new data connection, so this is somewhat unlikely corner case. However, it is possible that a misbehaving source could cause conntrack entries be created that could then interfere with new related connections.
Fix this in the OVS module by deleting the clashing conntrack entry after an expectation has been matched. This causes the following nf_conntrack_in() call also find the expectation and remove it when creating the new conntrack entry, as well as the forthcoming reply direction packets to match the new related connection instead of the old clashing conntrack entry.
--- net/openvswitch/conntrack.c | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-)
net/openvswitch/conntrack.c +29 -1
@@ -396,10 +396,38 @@ ovs_ct_expect_find(struct net *net, const struct nf_conntrack_zone *zone, u16 proto, const struct sk_buff *skb) { struct nf_conntrack_tuple tuple; +struct nf_conntrack_expect *exp;if (!nf_ct_get_tuplepr (skb,skb_network_offset (skb), proto, net, &tuple))return NULL ; -return __nf_ct_expect_find (net, zone, &tuple); + + exp =__nf_ct_expect_find (net, zone, &tuple); +if (exp) { +struct nf_conntrack_tuple_hash *h; + +/* Delete existing conntrack entry, if it clashes with the +* expectation. This can happen since conntrack ALGs do not +* check for clashes between (new) expectations and existing +* conntrack entries. nf_conntrack_in() will check the +* expectations only if a conntrack entry can not be found, +* which can lead to OVS finding the expectation (here) in the +* init direction, but which will not be removed by the +* nf_conntrack_in() call, if a matching conntrack entry is +* found instead. In this case all init direction packets +* would be reported as new related packets, while reply +* direction packets would be reported as un-related +* established packets. +*/ + h =nf_conntrack_find_get (net, zone, &tuple); +if (h) { +struct nf_conn *ct =nf_ct_tuplehash_to_ctrack (h); + +nf_ct_delete (ct,0 ,0 ); +nf_conntrack_put (&ct->ct_general); + } + } + +return exp; }/* This replicates logic from nf_conntrack_core.c that is not exported. */
Signature · 1 line
2.14.1
PATCH 77/190 netfilter: nf_ct_helper: permit cthelpers with different names via nfnetlink
In reply to Sasha LevinFrom: Liping Zhang <[email protected]>
[ Upstream commit 66e5a6b18bd09d0431e97cd3c162e76c5c2aebba ]
cthelpers added via nfnetlink may have the same tuple, i.e. except for the l3proto and l4proto, other fields are all zero. So even with the different names, we will also fail to add them:
# nfct helper add ssdp inet udp # nfct helper add tftp inet udp nfct v1.4.3: netlink error: File exists
So in order to avoid unpredictable behaviour, we should:
1. cthelpers can be selected by nft ct helper obj or xt_CT target, so report error if duplicated { name, l3proto, l4proto } tuple exist.
2. cthelpers can be selected by nf_ct_tuple_src_mask_cmp when nf_ct_auto_assign_helper is enabled, so also report error if duplicated { l3proto, l4proto, src-port } tuple exist.
Also note, if the cthelper is added from userspace, then the src-port will always be zero, it's invalid for nf_ct_auto_assign_helper, so there's no need to check the second point listed above.
--- net/netfilter/nf_conntrack_helper.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-)
net/netfilter/nf_conntrack_helper.c +21 -5
@@ -379,17 +379,33 @@ int nf_conntrack_helper_register(struct nf_conntrack_helper *me)struct nf_conntrack_tuple_mask mask = { .src.u.all =htons (0xFFFF ) };unsigned int h =helper_hash (&me->tuple);struct nf_conntrack_helper *cur; -int ret =0 ; +int ret =0 , i;BUG_ON (me->expect_policy ==NULL );BUG_ON (me->expect_class_max >=NF_CT_MAX_EXPECT_CLASSES );BUG_ON (strlen (me->name) >NF_CT_HELPER_NAME_LEN -1 );mutex_lock (&nf_ct_helper_mutex); -hlist_for_each_entry (cur, &nf_ct_helper_hash[h], hnode) { -if (nf_ct_tuple_src_mask_cmp (&cur->tuple, &me->tuple, &mask)) { - ret = -EEXIST ; - goto out; +for (i =0 ; i < nf_ct_helper_hsize; i++) { +hlist_for_each_entry (cur, &nf_ct_helper_hash[i], hnode) { +if (!strcmp (cur->name, me->name) && + (cur->tuple.src.l3num ==NFPROTO_UNSPEC || + cur->tuple.src.l3num == me->tuple.src.l3num) && + cur->tuple.dst.protonum == me->tuple.dst.protonum) { + ret = -EEXIST ; + goto out; + } + } + } + +/* avoid unpredictable behaviour for auto_assign_helper */ +if (!(me->flags &NF_CT_HELPER_F_USERSPACE )) { +hlist_for_each_entry (cur, &nf_ct_helper_hash[h], hnode) { +if (nf_ct_tuple_src_mask_cmp (&cur->tuple, &me->tuple, + &mask)) { + ret = -EEXIST ; + goto out; + } } }hlist_add_head_rcu (&me->hnode, &nf_ct_helper_hash[h]);
Signature · 1 line
2.14.1
PATCH 78/190 mmc: host: omap_hsmmc: checking for NULL instead of IS_ERR()
In reply to Sasha LevinFrom: Dan Carpenter <[email protected]>
[ Upstream commit ec5ab8933772c87f24ad62a4a602fe8949f423c2 ]
devm_pinctrl_get() returns error pointers, it never returns NULL.
--- drivers/mmc/host/omap_hsmmc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/mmc/host/omap_hsmmc.c +2 -2
@@ -1762,8 +1762,8 @@ static int omap_hsmmc_configure_wake_irq(struct omap_hsmmc_host *host)*/ if (host->pdata->controller_flags &OMAP_HSMMC_SWAKEUP_MISSING ) {struct pinctrl *p =devm_pinctrl_get (host->dev); -if (!p) { - ret = -ENODEV ; +if (IS_ERR (p)) { + ret =PTR_ERR (p); goto err_free_irq; }if (IS_ERR (pinctrl_lookup_state (p,PINCTRL_STATE_DEFAULT ))) {
Signature · 1 line
2.14.1
PATCH 79/190 tipc: check return value of nlmsg_new
In reply to Sasha LevinFrom: Pan Bian <[email protected]>
[ Upstream commit 78302fd405769c9a9379e9adda119d533dce2eed ]
Function nlmsg_new() will return a NULL pointer if there is no enough memory, and its return value should be checked before it is used. However, in function tipc_nl_node_get_monitor(), the validation of the return value of function nlmsg_new() is missed. This patch fixes the bug.
--- net/tipc/node.c | 2 ++ 1 file changed, 2 insertions(+)
net/tipc/node.c +2 -0
@@ -2094,6 +2094,8 @@ int tipc_nl_node_get_monitor(struct sk_buff *skb, struct genl_info *info)int err; msg.skb =nlmsg_new (NLMSG_GOODSIZE ,GFP_KERNEL ); +if (!msg.skb) +return -ENOMEM ; msg.portid = info->snd_portid; msg.seq = info->snd_seq;
Signature · 1 line
2.14.1
PATCH 80/190 wan: pc300too: abort path on failure
In reply to Sasha LevinFrom: Pan Bian <[email protected]>
[ Upstream commit 2a39e7aa8a98f777f0732ca7125b6c9668791760 ]
In function pc300_pci_init_one(), on the ioremap error path, function pc300_pci_remove_one() is called to free the allocated memory. However, the path is not terminated, and the freed memory will be used later, resulting in use-after-free bugs. This path fixes the bug.
--- drivers/net/wan/pc300too.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wan/pc300too.c +1 -0
@@ -347,6 +347,7 @@ static int pc300_pci_init_one(struct pci_dev *pdev, card->rambase == NULL) {pr_err ("ioremap() failed\n" );pc300_pci_remove_one (pdev); +return -ENOMEM ; }/* PLX PCI 9050 workaround for local configuration register read bug */
Signature · 1 line
2.14.1
PATCH 81/190 qlcnic: fix unchecked return value
In reply to Sasha LevinFrom: Pan Bian <[email protected]>
[ Upstream commit 91ec701a553cb3de470fd471c6fefe3ad1125455 ]
Function pci_find_ext_capability() may return 0, which is an invalid address. In function qlcnic_sriov_virtid_fn(), its return value is used without validation. This may result in invalid memory access bugs. This patch fixes the bug.
--- drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c +2 -0
@@ -128,6 +128,8 @@ static int qlcnic_sriov_virtid_fn(struct qlcnic_adapter *adapter, int vf_id)return 0 ; pos =pci_find_ext_capability (dev,PCI_EXT_CAP_ID_SRIOV ); +if (!pos) +return 0 ;pci_read_config_word (dev, pos +PCI_SRIOV_VF_OFFSET , &offset);pci_read_config_word (dev, pos +PCI_SRIOV_VF_STRIDE , &stride);
Signature · 1 line
2.14.1
PATCH 82/190 netfilter: nft_dynset: continue to next expr if _OP_ADD succeeded
In reply to Sasha LevinFrom: Liping Zhang <[email protected]>
[ Upstream commit 277a292835c196894ef895d5e1fd6170bb916f55 ]
Currently, after adding the following nft rules:
# nft add set x target1 { type ipv4_addr \; flags timeout \;}
# nft add rule x y set add ip daddr timeout 1d @target1 counterthe counters will always be zero despite of the elements are added to the dynamic set "target1" or not, as we will break the nft expr traversal unconditionally:
# nft list ruleset
...
set target1 {
...
elements = { 8.8.8.8 expires 23h59m53s}
}
chain output {
...
set add ip daddr timeout 1d @target1 counter packets 0 bytes 0
^ ^
...
}Since we add the elements to the set successfully, we should continue to the next expression.
Additionally, if elements are added to "flow table" successfully, we will _always_ continue to the next expr, even if the operation is _OP_ADD. So it's better to keep them to be consistent.
--- net/netfilter/nft_dynset.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
net/netfilter/nft_dynset.c +2 -3
@@ -82,8 +82,7 @@ static void nft_dynset_eval(const struct nft_expr *expr, nft_set_ext_exists(ext, NFT_SET_EXT_EXPIRATION)) { timeout = priv->timeout ? : set->timeout; *nft_set_ext_expiration (ext) = jiffies + timeout; - } else if (sexpr == NULL) - goto out; + }if (sexpr !=NULL ) sexpr->ops->eval (sexpr, regs, pkt);
@@ -92,7 +91,7 @@ static void nft_dynset_eval(const struct nft_expr *expr, regs->verdict.code =NFT_BREAK ;return ; } -out: +if (!priv->invert) regs->verdict.code =NFT_BREAK ; }
Signature · 1 line
2.14.1
PATCH 83/190 platform/x86: intel-vbtn: add volume up and down
In reply to Sasha LevinFrom: Maarten Maathuis <[email protected]>
[ Upstream commit 8d9e29972836b75eb74f533594999500a4c7cc19 ]
Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
--- drivers/platform/x86/intel-vbtn.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/platform/x86/intel-vbtn.c +4 -0
@@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {static const struct key_entry intel_vbtn_keymap[] = { {KE_IGNORE ,0xC0 , {KEY_POWER } },/* power key press */ {KE_KEY ,0xC1 , {KEY_POWER } },/* power key release */ + {KE_KEY ,0xC4 , {KEY_VOLUMEUP } },/* volume-up key press */ + {KE_IGNORE ,0xC5 , {KEY_VOLUMEUP } },/* volume-up key release */ + {KE_KEY ,0xC6 , {KEY_VOLUMEDOWN } },/* volume-down key press */ + {KE_IGNORE ,0xC7 , {KEY_VOLUMEDOWN } },/* volume-down key release */ {KE_END }, };
Signature · 1 line
2.14.1
PATCH 84/190 scsi: mac_esp: Replace bogus memory barrier with spinlock
In reply to Sasha LevinFrom: Finn Thain <[email protected]>
[ Upstream commit 4da2b1eb230ba4ad19b58984dc52e05b1073df5f ]
Commit da244654c66e ("[SCSI] mac_esp: fix for quadras with two esp chips") added mac_scsi_esp_intr() to handle the IRQ lines from a pair of on-board ESP chips (a normal shared IRQ did not work).
Proper mutual exclusion was missing from that patch. This patch fixes race conditions between comparison and assignment of esp_chips[] pointers.
--- drivers/scsi/mac_esp.c | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-)
drivers/scsi/mac_esp.c +23 -10
@@ -55,6 +55,7 @@ struct mac_esp_priv {int error; };static struct esp *esp_chips[2 ]; +static DEFINE_SPINLOCK (esp_chips_lock);#define MAC_ESP_GET_PRIV (esp) ((struct mac_esp_priv *) \ platform_get_drvdata((struct platform_device *) \
@@ -562,15 +563,18 @@ static int esp_mac_probe(struct platform_device *dev) } host->irq =IRQ_MAC_SCSI ; - esp_chips[dev->id] = esp; -mb (); -if (esp_chips[!dev->id] ==NULL ) { - err =request_irq (host->irq, mac_scsi_esp_intr,0 ,"ESP" ,NULL ); -if (err <0 ) { - esp_chips[dev->id] =NULL ; - goto fail_free_priv; - } + +/* The request_irq() call is intended to succeed for the first device +* and fail for the second device. +*/ + err =request_irq (host->irq, mac_scsi_esp_intr,0 ,"ESP" ,NULL ); +spin_lock (&esp_chips_lock); +if (err <0 && esp_chips[!dev->id] ==NULL ) { +spin_unlock (&esp_chips_lock); + goto fail_free_priv; } + esp_chips[dev->id] = esp; +spin_unlock (&esp_chips_lock); err =scsi_esp_register (esp, &dev->dev);if (err)
@@ -579,8 +583,13 @@ static int esp_mac_probe(struct platform_device *dev)return 0 ; fail_free_irq: -if (esp_chips[!dev->id] ==NULL ) +spin_lock (&esp_chips_lock); + esp_chips[dev->id] =NULL ; +if (esp_chips[!dev->id] ==NULL ) { +spin_unlock (&esp_chips_lock);free_irq (host->irq, esp); + }else +spin_unlock (&esp_chips_lock); fail_free_priv:kfree (mep); fail_free_command_block:
@@ -599,9 +608,13 @@ static int esp_mac_remove(struct platform_device *dev)scsi_esp_unregister (esp); +spin_lock (&esp_chips_lock); esp_chips[dev->id] =NULL ; -if (!(esp_chips[0 ] || esp_chips[1 ])) +if (esp_chips[!dev->id] ==NULL ) { +spin_unlock (&esp_chips_lock);free_irq (irq,NULL ); + }else +spin_unlock (&esp_chips_lock);kfree (mep);
Signature · 1 line
2.14.1
PATCH 85/190 infiniband/uverbs: Fix integer overflows
In reply to Sasha LevinFrom: Vlad Tsyrklevich <[email protected]>
[ Upstream commit 4f7f4dcfff2c19debbcdbcc861c325610a15e0c5 ]
The 'num_sge' variable is verfied to be smaller than the 'sge_count' variable; however, since both are user-controlled it's possible to cause an integer overflow for the kmalloc multiply on 32-bit platforms (num_sge and sge_count are both defined u32). By crafting an input that causes a smaller-than-expected allocation it's possible to write controlled data out-of-bounds.
--- drivers/infiniband/core/uverbs_cmd.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/infiniband/core/uverbs_cmd.c +12 -1
@@ -2491,9 +2491,13 @@ ssize_t ib_uverbs_destroy_qp(struct ib_uverbs_file *file,static void *alloc_wr (size_t wr_size,__u32 num_sge) { +if (num_sge >= (U32_MAX -ALIGN (wr_size,sizeof (struct ib_sge ))) / +sizeof (struct ib_sge )) +return NULL ; +return kmalloc (ALIGN (wr_size,sizeof (struct ib_sge )) + num_sge *sizeof (struct ib_sge ),GFP_KERNEL ); -}; +} ssize_t ib_uverbs_post_send(struct ib_uverbs_file *file, struct ib_device *ib_dev,
@@ -2720,6 +2724,13 @@ static struct ib_recv_wr *ib_uverbs_unmarshall_recv(const char __user *buf, goto err; } +if (user_wr->num_sge >= + (U32_MAX -ALIGN (sizeof *next,sizeof (struct ib_sge ))) / +sizeof (struct ib_sge )) { + ret = -EINVAL ; + goto err; + } + next =kmalloc (ALIGN (sizeof *next,sizeof (struct ib_sge )) + user_wr->num_sge *sizeof (struct ib_sge ),GFP_KERNEL );
Signature · 1 line
2.14.1
PATCH 86/190 pNFS: Fix use after free issues in pnfs_do_read()
In reply to Sasha LevinFrom: Trond Myklebust <[email protected]>
[ Upstream commit 6aeafd05eca9bc8ab6b03d7e56d09ffd18190f44 ]
The assumption should be that if the caller returns PNFS_ATTEMPTED, then hdr has been consumed, and so we should not be testing hdr->task.tk_status. If the caller returns PNFS_TRY_AGAIN, then we need to recoalesce and free hdr.
--- fs/nfs/pnfs.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
fs/nfs/pnfs.c +13 -3
@@ -2308,10 +2308,20 @@ pnfs_do_read(struct nfs_pageio_descriptor *desc, struct nfs_pgio_header *hdr)enum pnfs_try_status trypnfs; trypnfs =pnfs_try_to_read_data (hdr, call_ops, lseg); -if (trypnfs ==PNFS_TRY_AGAIN ) -pnfs_read_resend_pnfs (hdr); -if (trypnfs ==PNFS_NOT_ATTEMPTED || hdr->task.tk_status) +switch (trypnfs) { +case PNFS_NOT_ATTEMPTED :pnfs_read_through_mds (desc, hdr); +case PNFS_ATTEMPTED : +break ; +case PNFS_TRY_AGAIN : +/* cleanup hdr and prepare to redo pnfs */ +if (!test_and_set_bit (NFS_IOHDR_REDO , &hdr->flags)) { +struct nfs_pgio_mirror *mirror =nfs_pgio_current_mirror (desc); +list_splice_init (&hdr->pages, &mirror->pg_list); + mirror->pg_recoalesce =1 ; + } + hdr->mds_ops->rpc_release (hdr); + } }static void pnfs_readhdr_free (struct nfs_pgio_header *hdr)
Signature · 1 line
2.14.1
PATCH 87/190 xprtrdma: Cancel refresh worker during buffer shutdown
In reply to Sasha LevinFrom: Chuck Lever <[email protected]>
[ Upstream commit 9378b274e1eb6925db315e345f48850d2d5d9789 ]
Trying to create MRs while the transport is being torn down can cause a crash.
--- net/sunrpc/xprtrdma/verbs.c | 1 + 1 file changed, 1 insertion(+)
net/sunrpc/xprtrdma/verbs.c +1 -0
@@ -1054,6 +1054,7 @@ void rpcrdma_buffer_destroy(struct rpcrdma_buffer *buf) {cancel_delayed_work_sync (&buf->rb_recovery_worker); +cancel_delayed_work_sync (&buf->rb_refresh_worker);while (!list_empty (&buf->rb_recv_bufs)) {struct rpcrdma_rep *rep;
Signature · 1 line
2.14.1
PATCH 88/190 NFS: don't try to cross a mountpount when there isn't one there.
In reply to Sasha LevinFrom: NeilBrown <[email protected]>
[ Upstream commit 99bbf6ecc694dfe0b026e15359c5aa2a60b97a93 ]
consider the sequence of commands:
mkdir -p /import/nfs /import/bind /import/etc
mount --bind / /import/bind
mount --make-private /import/bind
mount --bind /import/etc /import/bind/etc
exportfs -o rw,no_root_squash,crossmnt,async,no_subtree_check localhost:/ mount -o vers=4 localhost:/ /import/nfs
ls -l /import/nfs/etc
You would not expect this to report a stale file handle. Yet it does.
The manipulations under /import/bind cause the dentry for /etc to get the DCACHE_MOUNTED flag set, even though nothing is mounted on /etc. This causes nfsd to call nfsd_cross_mnt() even though there is no mountpoint. So an upcall to mountd for "/etc" is performed.
The 'crossmnt' flag on the export of / causes mountd to report that /etc is exported as it is a descendant of /. It assumes the kernel wouldn't ask about something that wasn't a mountpoint. The filehandle returned identifies the filesystem and the inode number of /etc.
When this filehandle is presented to rpc.mountd, via "nfsd.fh", the inode cannot be found associated with any name in /etc/exports, or with any mountpoint listed by getmntent(). So rpc.mountd says the filehandle doesn't exist. Hence ESTALE.
This is fixed by teaching nfsd not to trust DCACHE_MOUNTED too much. It is just a hint, not a guarantee.
Change nfsd_mountpoint() to return '1' for a certain mountpoint, '2' for a possible mountpoint, and 0 otherwise.
Then change nfsd_crossmnt() to check if follow_down() actually found a mountpount and, if not, to avoid performing a lookup if the location is not known to certainly require an export-point.
--- fs/nfsd/vfs.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)
fs/nfsd/vfs.c +20 -4
@@ -94,6 +94,12 @@ nfsd_cross_mnt(struct svc_rqst *rqstp, struct dentry **dpp, err =follow_down (&path);if (err <0 ) goto out; +if (path.mnt == exp->ex_path.mnt && path.dentry == dentry && +nfsd_mountpoint (dentry, exp) ==2 ) { +/* This is only a mountpoint in some other namespace */ +path_put (&path); + goto out; + } exp2 =rqst_exp_get_by_name (rqstp, &path);if (IS_ERR (exp2)) {
@@ -167,16 +173,26 @@ static int nfsd_lookup_parent(struct svc_rqst *rqstp, struct dentry *dparent, st/* * For nfsd purposes, we treat V4ROOT exports as though there was an * export at *every* directory. +* We return: +* '1' if this dentry *must* be an export point, +* '2' if it might be, if there is really a mount here, and +* '0' if there is no chance of an export point here. */ int nfsd_mountpoint (struct dentry *dentry,struct svc_export *exp) { -if (d_mountpoint (dentry)) +if (!d_inode (dentry)) +return 0 ; +if (exp->ex_flags &NFSEXP_V4ROOT )return 1 ;if (nfsd4_is_junction (dentry))return 1 ; -if (!(exp->ex_flags &NFSEXP_V4ROOT )) -return 0 ; -return d_inode (dentry) !=NULL ; +if (d_mountpoint (dentry)) +/* +* Might only be a mountpoint in a different namespace, +* but we need to check. +*/ +return 2 ; +return 0 ; } __be32
Signature · 1 line
2.14.1
PATCH 89/190 iio: st_pressure: st_accel: Initialise sensor platform data properly
In reply to Sasha LevinFrom: Shrirang Bagul <[email protected]>
[ Upstream commit 7383d44b84c94aaca4bf695a6bd8a69f2295ef1a ]
This patch fixes the sensor platform data initialisation for st_pressure and st_accel device drivers. Without this patch, the driver fails to register the sensors when the user removes and re-loads the driver.
1. Unload the kernel modules for st_pressure
$ sudo rmmod st_pressure_i2c $ sudo rmmod st_pressure
2. Re-load the driver
$ sudo insmod st_pressure $ sudo insmod st_pressure_i2c
--- drivers/iio/accel/st_accel_core.c | 7 ++++--- drivers/iio/pressure/st_pressure_core.c | 8 ++++---- 2 files changed, 8 insertions(+), 7 deletions(-)
drivers/iio/accel/st_accel_core.c +4 -3
@@ -827,6 +827,8 @@ static const struct iio_trigger_ops st_accel_trigger_ops = {int st_accel_common_probe (struct iio_dev *indio_dev) {struct st_sensor_data *adata =iio_priv (indio_dev); +struct st_sensors_platform_data *pdata = + (struct st_sensors_platform_data *)adata->dev->platform_data;int irq = adata->get_irq_data_ready (indio_dev);int err;
@@ -853,9 +855,8 @@ int st_accel_common_probe(struct iio_dev *indio_dev) &adata->sensor_settings->fs.fs_avl[0 ]; adata->odr = adata->sensor_settings->odr.odr_avl[0 ].hz; -if (!adata->dev->platform_data) - adata->dev->platform_data = - (struct st_sensors_platform_data *)&default_accel_pdata; +if (!pdata) + pdata = (struct st_sensors_platform_data *)&default_accel_pdata; err =st_sensors_init_sensor (indio_dev, adata->dev->platform_data);if (err <0 )
drivers/iio/pressure/st_pressure_core.c +4 -4
@@ -638,6 +638,8 @@ static const struct iio_trigger_ops st_press_trigger_ops = {int st_press_common_probe (struct iio_dev *indio_dev) {struct st_sensor_data *press_data =iio_priv (indio_dev); +struct st_sensors_platform_data *pdata = + (struct st_sensors_platform_data *)press_data->dev->platform_data;int irq = press_data->get_irq_data_ready (indio_dev);int err;
@@ -673,10 +675,8 @@ int st_press_common_probe(struct iio_dev *indio_dev) press_data->odr = press_data->sensor_settings->odr.odr_avl[0 ].hz;/* Some devices don't support a data ready pin. */ -if (!press_data->dev->platform_data && - press_data->sensor_settings->drdy_irq.addr) - press_data->dev->platform_data = - (struct st_sensors_platform_data *)&default_press_pdata; +if (!pdata && press_data->sensor_settings->drdy_irq.addr) + pdata = (struct st_sensors_platform_data *)&default_press_pdata; err =st_sensors_init_sensor (indio_dev, press_data->dev->platform_data);if (err <0 )
Signature · 1 line
2.14.1
PATCH 90/190 mt7601u: check return value of alloc_skb
In reply to Sasha LevinFrom: Pan Bian <[email protected]>
[ Upstream commit 5fb01e91daf84ad1e50edfcf63116ecbe31e7ba7 ]
Function alloc_skb() will return a NULL pointer if there is no enough memory. However, in function mt7601u_mcu_msg_alloc(), its return value is not validated before it is used. This patch fixes it.
--- drivers/net/wireless/mediatek/mt7601u/mcu.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/net/wireless/mediatek/mt7601u/mcu.c +8 -2
@@ -66,8 +66,10 @@ mt7601u_mcu_msg_alloc(struct mt7601u_dev *dev, const void *data, int len)WARN_ON (len %4 );/* if length is not divisible by 4 we need to pad */ skb =alloc_skb (len +MT_DMA_HDR_LEN +4 ,GFP_KERNEL ); -skb_reserve (skb,MT_DMA_HDR_LEN ); -memcpy (skb_put (skb, len), data, len); +if (skb) { +skb_reserve (skb,MT_DMA_HDR_LEN ); +memcpy (skb_put (skb, len), data, len); + }return skb; }
@@ -170,6 +172,8 @@ static int mt7601u_mcu_function_select(struct mt7601u_dev *dev, }; skb =mt7601u_mcu_msg_alloc (dev, &msg,sizeof (msg)); +if (!skb) +return -ENOMEM ;return mt7601u_mcu_msg_send (dev, skb,CMD_FUN_SET_OP , func ==5 ); }
@@ -205,6 +209,8 @@ mt7601u_mcu_calibrate(struct mt7601u_dev *dev, enum mcu_calibrate cal, u32 val) }; skb =mt7601u_mcu_msg_alloc (dev, &msg,sizeof (msg)); +if (!skb) +return -ENOMEM ;return mt7601u_mcu_msg_send (dev, skb,CMD_CALIBRATION_OP , true); }
Signature · 1 line
2.14.1
PATCH 91/190 libertas: check return value of alloc_workqueue
In reply to Sasha LevinFrom: Pan Bian <[email protected]>
[ Upstream commit dc3f89c38a8406554ffeffa370aad086a9c5e9de ]
Function alloc_workqueue() will return a NULL pointer if there is no enough memory, and its return value should be validated before using. However, in function if_spi_probe(), its return value is not checked. This may result in a NULL dereference bug. This patch fixes the bug.
--- drivers/net/wireless/marvell/libertas/if_spi.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/wireless/marvell/libertas/if_spi.c +5 -0
@@ -1181,6 +1181,10 @@ static int if_spi_probe(struct spi_device *spi)/* Initialize interrupt handling stuff. */ card->workqueue =alloc_workqueue ("libertas_spi" ,WQ_MEM_RECLAIM ,0 ); +if (!card->workqueue) { + err = -ENOMEM ; + goto remove_card; + }INIT_WORK (&card->packet_work, if_spi_host_to_card_worker);INIT_WORK (&card->resume_work, if_spi_resume_worker);
@@ -1209,6 +1213,7 @@ static int if_spi_probe(struct spi_device *spi)free_irq (spi->irq, card); terminate_workqueue:destroy_workqueue (card->workqueue); +remove_card:lbs_remove_card (priv);/* will call free_netdev */ free_card:free_if_spi_card (card);
Signature · 1 line
2.14.1
PATCH 92/190 rndis_wlan: add return value validation
In reply to Sasha LevinFrom: Pan Bian <[email protected]>
[ Upstream commit 9dc7efd3978aa67ae598129d2a3f240b390ce508 ]
Function create_singlethread_workqueue() will return a NULL pointer if there is no enough memory, and its return value should be validated before using. However, in function rndis_wlan_bind(), its return value is not checked. This may cause NULL dereference bugs. This patch fixes it.
--- drivers/net/wireless/rndis_wlan.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/wireless/rndis_wlan.c +4 -0
@@ -3427,6 +3427,10 @@ static int rndis_wlan_bind(struct usbnet *usbdev, struct usb_interface *intf)/* because rndis_command() sleeps we need to use workqueue */ priv->workqueue =create_singlethread_workqueue ("rndis_wlan" ); +if (!priv->workqueue) { +wiphy_free (wiphy); +return -ENOMEM ; + }INIT_WORK (&priv->work, rndis_wlan_worker);INIT_DELAYED_WORK (&priv->dev_poller_work, rndis_device_poller);INIT_DELAYED_WORK (&priv->scan_work, rndis_get_scan_results);
Signature · 1 line
2.14.1
PATCH 93/190 Btrfs: fix incorrect space accounting after failure to insert inline extent
In reply to Sasha LevinFrom: Filipe Manana <[email protected]>
[ Upstream commit 1c81ba237bcecad9bc885a1ddcf02d725ea38482 ]
When using compression, if we fail to insert an inline extent we incorrectly end up attempting to free the reserved data space twice, once through extent_clear_unlock_delalloc(), because we pass it the flag EXTENT_DO_ACCOUNTING, and once through a direct call to btrfs_free_reserved_data_space_noquota(). This results in a trace like the following:
[ 834.576240] ------------[ cut here ]------------ [ 834.576825] WARNING: CPU: 2 PID: 486 at fs/btrfs/extent-tree.c:4316 btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs] [ 834.579501] Modules linked in: btrfs crc32c_generic xor raid6_pq ppdev i2c_piix4 acpi_cpufreq psmouse tpm_tis parport_pc pcspkr serio_raw tpm_tis_core sg parport evdev i2c_core tpm button loop autofs4 ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix virtio_pci libata virtio_ring virtio scsi_mod e1000 floppy [last unloaded: btrfs] [ 834.592116] CPU: 2 PID: 486 Comm: kworker/u32:4 Not tainted 4.10.0-rc8-btrfs-next-37+ #2 [ 834.593316] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 834.595273] Workqueue: btrfs-delalloc btrfs_delalloc_helper [btrfs] [ 834.596103] Call Trace: [ 834.596103] dump_stack+0x67/0x90 [ 834.596103] __warn+0xc2/0xdd [ 834.596103] warn_slowpath_null+0x1d/0x1f [ 834.596103] btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs] [ 834.596103] compress_file_range.constprop.42+0x2fa/0x3fc [btrfs] [ 834.596103] ? submit_compressed_extents+0x3a7/0x3a7 [btrfs] [ 834.596103] async_cow_start+0x32/0x4d [btrfs] [ 834.596103] btrfs_scrubparity_helper+0x187/0x3e7 [btrfs] [ 834.596103] btrfs_delalloc_helper+0xe/0x10 [btrfs] [ 834.596103] process_one_work+0x273/0x4e4 [ 834.596103] worker_thread+0x1eb/0x2ca [ 834.596103] ? rescuer_thread+0x2b6/0x2b6 [ 834.596103] kthread+0x100/0x108 [ 834.596103] ? __list_del_entry+0x22/0x22 [ 834.596103] ret_from_fork+0x2e/0x40 [ 834.611656] ---[ end trace 719902fe6bdef08f ]---
So fix this by not calling directly btrfs_free_reserved_data_space_noquota() if an error happened.
--- fs/btrfs/inode.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/btrfs/inode.c +4 -2
@@ -567,8 +567,10 @@ static noinline void compress_file_range(struct inode *inode,PAGE_SET_WRITEBACK | page_error_op | PAGE_END_WRITEBACK); -btrfs_free_reserved_data_space_noquota (inode, start, - end - start +1 ); +if (ret ==0 ) +btrfs_free_reserved_data_space_noquota (inode, + start, + end - start +1 ); goto free_pages_out; } }
Signature · 1 line
2.14.1
PATCH 94/190 Btrfs: send, fix file hole not being preserved due to inline extent
In reply to Sasha LevinFrom: Filipe Manana <[email protected]>
[ Upstream commit e1cbfd7bf6dabdac561c75d08357571f44040a45 ]
Normally we don't have inline extents followed by regular extents, but there's currently at least one harmless case where this happens. For example, when the page size is 4Kb and compression is enabled:
$ mkfs.btrfs -f /dev/sdb $ mount -o compress /dev/sdb /mnt $ xfs_io -f -c "pwrite -S 0xaa 0 4K" -c "fsync" /mnt/foobar $ xfs_io -c "pwrite -S 0xbb 8K 4K" -c "fsync" /mnt/foobar
In this case we get a compressed inline extent, representing 4Kb of data, followed by a hole extent and then a regular data extent. The inline extent was not expanded/converted to a regular extent exactly because it represents 4Kb of data. This does not cause any apparent problem (such as the issue solved by commit e1699d2d7bf6 ("btrfs: add missing memset while reading compressed inline extents")) except trigger an unexpected case in the incremental send code path that makes us issue an operation to write a hole when it's not needed, resulting in more writes at the receiver and wasting space at the receiver.
So teach the incremental send code to deal with this particular case.
The issue can be currently triggered by running fstests btrfs/137 with compression enabled (MOUNT_OPTIONS="-o compress" ./check btrfs/137).
--- fs/btrfs/send.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-)
fs/btrfs/send.c +21 -2
@@ -5156,13 +5156,19 @@ static int is_extent_unchanged(struct send_ctx *sctx,while (key.offset < ekey->offset + left_len) { ei = btrfs_item_ptr(eb, slot, struct btrfs_file_extent_item); right_type =btrfs_file_extent_type (eb, ei); -if (right_type !=BTRFS_FILE_EXTENT_REG ) { +if (right_type !=BTRFS_FILE_EXTENT_REG && + right_type !=BTRFS_FILE_EXTENT_INLINE ) { ret =0 ; goto out; } right_disknr =btrfs_file_extent_disk_bytenr (eb, ei); - right_len =btrfs_file_extent_num_bytes (eb, ei); +if (right_type ==BTRFS_FILE_EXTENT_INLINE ) { + right_len =btrfs_file_extent_inline_len (eb, slot, ei); + right_len =PAGE_ALIGN (right_len); + }else { + right_len =btrfs_file_extent_num_bytes (eb, ei); + } right_offset =btrfs_file_extent_offset (eb, ei); right_gen =btrfs_file_extent_generation (eb, ei);
@@ -5176,6 +5182,19 @@ static int is_extent_unchanged(struct send_ctx *sctx, goto out; } +/* +* We just wanted to see if when we have an inline extent, what +* follows it is a regular extent (wanted to check the above +* condition for inline extents too). This should normally not +* happen but it's possible for example when we have an inline +* compressed extent representing data with a size matching +* the page size (currently the same as sector size). +*/ +if (right_type ==BTRFS_FILE_EXTENT_INLINE ) { + ret =0 ; + goto out; + } + left_offset_fixed = left_offset;if (key.offset < ekey->offset) {/* Fix the right offset for 2a and 7. */
Signature · 1 line
2.14.1
PATCH 95/190 Btrfs: fix extent map leak during fallocate error path
In reply to Sasha LevinFrom: Filipe Manana <[email protected]>
[ Upstream commit be2d253cc98244765323a7c94cc1ac5cd5a17072 ]
If the call to btrfs_qgroup_reserve_data() failed, we were leaking an extent map structure. The failure can happen either due to an -ENOMEM condition or, when quotas are enabled, due to -EDQUOT for example.
--- fs/btrfs/file.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/btrfs/file.c +3 -1
@@ -2817,8 +2817,10 @@ static long btrfs_fallocate(struct file *file, int mode, } ret =btrfs_qgroup_reserve_data (inode, cur_offset, last_byte - cur_offset); -if (ret <0 ) +if (ret <0 ) { +free_extent_map (em);break ; + } }else {/* * Do not need to reserve unwritten extent for this
Signature · 1 line
2.14.1
PATCH 96/190 orangefs: do not wait for timeout if umounting
In reply to Sasha LevinFrom: Martin Brandenburg <[email protected]>
[ Upstream commit b5a9d61eebdd0016ccb383b25a5c3d04977a6549 ]
When the computer is turned off, all the processes are killed and then all the filesystems are umounted. OrangeFS should not wait for the userspace daemon to come back in that case.
This only works for plain umount(2). To actually take advantage of this interactively, `umount -f' is needed; otherwise umount will issue a statfs first, which will wait for the userspace daemon to come back.
--- fs/orangefs/waitqueue.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
fs/orangefs/waitqueue.c +8 -1
@@ -124,7 +124,14 @@ int service_operation(struct orangefs_kernel_op_s *op,gossip_debug (GOSSIP_WAIT_DEBUG ,"%s:client core is NOT in service.\n" , __func__); - timeout = op_timeout_secs *HZ ; +/* +* Don't wait for the userspace component to return if +* the filesystem is being umounted anyway. +*/ +if (op->upcall.type ==ORANGEFS_VFS_OP_FS_UMOUNT ) + timeout =0 ; +else + timeout = op_timeout_secs *HZ ; }spin_unlock (&orangefs_request_list_lock);
Signature · 1 line
2.14.1
PATCH 97/190 mac80211: don't parse encrypted management frames in ieee80211_frame_acked
In reply to Sasha LevinFrom: Emmanuel Grumbach <[email protected]>
[ Upstream commit cf147085fdda044622973a12e4e06f1c753ab677 ]
ieee80211_frame_acked is called when a frame is acked by the peer. In case this is a management frame, we check if this an SMPS frame, in which case we can update our antenna configuration.
When we parse the management frame we look at the category in case it is an action frame. That byte sits after the IV in case the frame was encrypted. This means that if the frame was encrypted, we basically look at the IV instead of looking at the category. It is then theorically possible that we think that an SMPS action frame was acked where really we had another frame that was encrypted.
Since the only management frame whose ack needs to be tracked is the SMPS action frame, and that frame is not a robust management frame, it will never be encrypted. The easiest way to fix this problem is then to not look at frames that were encrypted.
--- net/mac80211/status.c | 1 + 1 file changed, 1 insertion(+)
net/mac80211/status.c +1 -0
@@ -200,6 +200,7 @@ static void ieee80211_frame_acked(struct sta_info *sta, struct sk_buff *skb) }if (ieee80211_is_action (mgmt->frame_control) && + !ieee80211_has_protected (mgmt->frame_control) && mgmt->u.action.category ==WLAN_CATEGORY_HT && mgmt->u.action.u.ht_smps.action ==WLAN_HT_ACTION_SMPS &&ieee80211_sdata_running (sdata)) {
Signature · 1 line
2.14.1
PATCH 98/190 ACPICA: iasl: Fix IORT SMMU GSI disassembling
In reply to Sasha LevinFrom: Lv Zheng <[email protected]>
[ Upstream commit bb1e23e66e6237ff7a1824b37366540a89149c33 ]
ACPICA commit 637b88de24a78c20478728d9d66632b06fcaa5bf
If the IORT template is compiled and then iort.aml binary disassembled to iort.dsl, SMMUv1 node lists incorrect offset for SMMU_Nsg_cfg_irpt Interrupt:
[0ECh 0236 8] SMMU_Nsg_irpt Interrupt : 0000000000000000
[0ECh 0236 8] SMMU_Nsg_cfg_irpt Interrupt : 0000000000000000
This is because iasl hasn't implemented SMMU GSI decoding yet.
This patch fixes this issue by preparing structures for decoding IORT SMMU GSI. ACPICA BZ 1340, reported by Alexei Fedorov, fixed by Lv Zheng.
--- include/acpi/actbl2.h | 9 +++++++++ 1 file changed, 9 insertions(+)
include/acpi/actbl2.h +9 -0
@@ -783,6 +783,15 @@ struct acpi_iort_smmu {#define ACPI_IORT_SMMU_DVM_SUPPORTED (1)#define ACPI_IORT_SMMU_COHERENT_WALK (1<<1) +/* Global interrupt format */ + +struct acpi_iort_smmu_gsi { +u32 nsg_irpt; +u32 nsg_irpt_flags; +u32 nsg_cfg_irpt; +u32 nsg_cfg_irpt_flags; +}; +struct acpi_iort_smmu_v3 {u64 base_address;/* SMMUv3 base address */ u32 flags;
Signature · 1 line
2.14.1
PATCH 99/190 iio: hid-sensor: fix return of -EINVAL on invalid values in ret or value
In reply to Sasha LevinFrom: Colin Ian King <[email protected]>
[ Upstream commit c894acc7bf400d039bf740420b22f0b71b7fb504 ]
Ensure that when an invalid value in ret or value is found -EINVAL is returned. A previous commit broke the way the return error is being returned and instead caused the return code in ret to be re-assigned rather than be returned.
--- drivers/iio/common/hid-sensors/hid-sensor-attributes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/iio/common/hid-sensors/hid-sensor-attributes.c +2 -2
@@ -215,7 +215,7 @@ int hid_sensor_write_samp_freq_value(struct hid_sensor_common *st, ret =sensor_hub_set_feature (st->hsdev, st->poll.report_id, st->poll.index,sizeof (value), &value);if (ret <0 || value <0 ) - ret = -EINVAL ; +return -EINVAL ; ret = sensor_hub_get_feature(st->hsdev, st->poll.report_id,
@@ -265,7 +265,7 @@ int hid_sensor_write_raw_hyst_value(struct hid_sensor_common *st, st->sensitivity.index,sizeof (value), &value);if (ret <0 || value <0 ) - ret = -EINVAL ; +return -EINVAL ; ret = sensor_hub_get_feature(st->hsdev, st->sensitivity.report_id,
Signature · 1 line
2.14.1
PATCH 100/190 dt-bindings: mfd: axp20x: Add "xpowers,master-mode" property for AXP806 PMICs
In reply to Sasha LevinFrom: Rask Ingemann Lambertsen <[email protected]>
[ Upstream commit 8461cf20d17e0090e9236b73d25b31be4f7fadc5 ]
commit b101829a029a ("mfd: axp20x: Fix AXP806 access errors on cold boot") was intended to fix the case where a board uses an AXP806 in slave mode, but the boot loader leaves it in master mode for lack of AXP806 support. But now the driver breaks on boards where the PMIC is operating in master mode. To let the device tree describe which mode of operation is needed, this patch introduces a new property "xpowers,master-mode".
--- Documentation/devicetree/bindings/mfd/axp20x.txt | 3 +++ 1 file changed, 3 insertions(+)
Documentation/devicetree/bindings/mfd/axp20x.txt +3 -0
@@ -28,6 +28,9 @@ Optional properties: regulator to drive the OTG VBus, rather then as an input pin which signals whether the board is driving OTG VBus or not. +- x-powers,master-mode: Boolean (axp806 only). Set this when the PMIC is + wired for master mode. The default is slave mode. + - <input>-supply: a phandle to the regulator supply node. May be omitted if inputs are unregulated, such as using the IPSOUT output from the PMIC.
Signature · 1 line
2.14.1
PATCH 101/190 mfd: palmas: Reset the POWERHOLD mux during power off
In reply to Sasha LevinFrom: Keerthy <[email protected]>
[ Upstream commit 85fdaf8eb9bbec1f0f8a52fd5d85659d60738816 ]
POWERHOLD signal has higher priority over the DEV_ON bit. So power off will not happen if the POWERHOLD is held high. Hence reset the MUX to GPIO_7 mode to release the POWERHOLD and the DEV_ON bit to take effect to power off the PMIC.
PMIC Power off happens in dire situations like thermal shutdown so irrespective of the POWERHOLD setting go ahead and turn off the powerhold. Currently poweroff is broken on boards that have powerhold enabled. This fixes poweroff on those boards.
--- drivers/mfd/palmas.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/mfd/palmas.c +14 -0
@@ -430,6 +430,20 @@ static void palmas_power_off(void) {unsigned int addr;int ret, slave; +struct device_node *np = palmas_dev->dev->of_node; + +if (of_property_read_bool (np,"ti,palmas-override-powerhold" )) { + addr =PALMAS_BASE_TO_REG (PALMAS_PU_PD_OD_BASE , +PALMAS_PRIMARY_SECONDARY_PAD2 ); + slave =PALMAS_BASE_TO_SLAVE (PALMAS_PU_PD_OD_BASE ); + + ret =regmap_update_bits (palmas_dev->regmap[slave], addr, +PALMAS_PRIMARY_SECONDARY_PAD2_GPIO_7_MASK ,0 ); +if (ret) +dev_err (palmas_dev->dev, +"Unable to write PRIMARY_SECONDARY_PAD2 %d\n" , + ret); + }if (!palmas_dev)return ;
Signature · 1 line
2.14.1
PATCH 102/190 mtip32xx: use runtime tag to initialize command header
In reply to Sasha LevinFrom: Ming Lei <[email protected]>
[ Upstream commit a4e84aae8139aca9fbfbced1f45c51ca81b57488 ]
mtip32xx supposes that 'request_idx' passed to .init_request() is tag of the request, and use that as request's tag to initialize command header.
After MQ IO scheduler is in, request tag assigned isn't same with the request index anymore, so cause strange hardware failure on mtip32xx, even whole system panic is triggered.
This patch fixes the issue by initializing command header via request's real tag.
--- drivers/block/mtip32xx/mtip32xx.c | 36 ++++++++++++++++++++++++------------ 1 file changed, 24 insertions(+), 12 deletions(-)
drivers/block/mtip32xx/mtip32xx.c +24 -12
@@ -169,6 +169,25 @@ static bool mtip_check_surprise_removal(struct pci_dev *pdev)return false;/* device present */ } +/* we have to use runtime tag to setup command header */ +static void mtip_init_cmd_header (struct request *rq) +{ +struct driver_data *dd = rq->q->queuedata; +struct mtip_cmd *cmd =blk_mq_rq_to_pdu (rq); +u32 host_cap_64 =readl (dd->mmio +HOST_CAP ) &HOST_CAP_64 ; + +/* Point the command headers at the command tables. */ + cmd->command_header = dd->port->command_list + + (sizeof (struct mtip_cmd_hdr ) * rq->tag); + cmd->command_header_dma = dd->port->command_list_dma + + (sizeof (struct mtip_cmd_hdr ) * rq->tag); + +if (host_cap_64) + cmd->command_header->ctbau = __force_bit2int cpu_to_le32((cmd->command_dma >> 16) >> 16); + + cmd->command_header->ctba = __force_bit2int cpu_to_le32(cmd->command_dma & 0xFFFFFFFF); +} +static struct mtip_cmd *mtip_get_int_command (struct driver_data *dd) {struct request *rq;
@@ -180,6 +199,9 @@ static struct mtip_cmd *mtip_get_int_command(struct driver_data *dd)if (IS_ERR (rq))return NULL ; +/* Internal cmd isn't submitted via .queue_rq */ +mtip_init_cmd_header (rq); +return blk_mq_rq_to_pdu (rq); }
@@ -3811,6 +3833,8 @@ static int mtip_queue_rq(struct blk_mq_hw_ctx *hctx,struct request *rq = bd->rq;int ret; +mtip_init_cmd_header (rq); +if (unlikely (mtip_check_unal_depth (hctx, rq)))return BLK_MQ_RQ_QUEUE_BUSY ;
@@ -3842,7 +3866,6 @@ static int mtip_init_cmd(void *data, struct request *rq, unsigned int hctx_idx, {struct driver_data *dd = data;struct mtip_cmd *cmd =blk_mq_rq_to_pdu (rq); -u32 host_cap_64 =readl (dd->mmio +HOST_CAP ) &HOST_CAP_64 ;/* * For flush requests, request_idx starts at the end of the
@@ -3859,17 +3882,6 @@ static int mtip_init_cmd(void *data, struct request *rq, unsigned int hctx_idx,memset (cmd->command,0 ,CMD_DMA_ALLOC_SZ ); -/* Point the command headers at the command tables. */ - cmd->command_header = dd->port->command_list + - (sizeof (struct mtip_cmd_hdr ) * request_idx); - cmd->command_header_dma = dd->port->command_list_dma + - (sizeof (struct mtip_cmd_hdr ) * request_idx); - -if (host_cap_64) - cmd->command_header->ctbau = __force_bit2int cpu_to_le32((cmd->command_dma >> 16) >> 16); - - cmd->command_header->ctba = __force_bit2int cpu_to_le32(cmd->command_dma & 0xFFFFFFFF); -sg_init_table (cmd->sg,MTIP_MAX_SG );return 0 ; }
Signature · 1 line
2.14.1
PATCH 103/190 x86/KASLR: Fix kexec kernel boot crash when KASLR randomization fails
In reply to Sasha LevinFrom: Baoquan He <[email protected]>
[ Upstream commit da63b6b20077469bd6bd96e07991ce145fc4fbc4 ]
Dave found that a kdump kernel with KASLR enabled will reset to the BIOS immediately if physical randomization failed to find a new position for the kernel. A kernel with the 'nokaslr' option works in this case.
The reason is that KASLR will install a new page table for the identity mapping, while it missed building it for the original kernel location if KASLR physical randomization fails.
This only happens in the kexec/kdump kernel, because the identity mapping has been built for kexec/kdump in the 1st kernel for the whole memory by calling init_pgtable(). Here if physical randomizaiton fails, it won't build the identity mapping for the original area of the kernel but change to a new page table '_pgtable'. Then the kernel will triple fault immediately caused by no identity mappings.
The normal kernel won't see this bug, because it comes here via startup_32() and CR3 will be set to _pgtable already. In startup_32() the identity mapping is built for the 0~4G area. In KASLR we just append to the existing area instead of entirely overwriting it for on-demand identity mapping building. So the identity mapping for the original area of kernel is still there.
To fix it we just switch to the new identity mapping page table when physical KASLR succeeds. Otherwise we keep the old page table unchanged just like "nokaslr" does.
--- arch/x86/boot/compressed/kaslr.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
arch/x86/boot/compressed/kaslr.c +9 -2
@@ -460,10 +460,17 @@ void choose_random_location(unsigned long input,add_identity_map (random_addr, output_size); *output = random_addr; } + +/* +* This loads the identity mapping page table. +* This should only be done if a new physical address +* is found for the kernel, otherwise we should keep +* the old page table to make it be like the "nokaslr" +* case. +*/ +finalize_identity_maps (); } -/* This actually loads the identity pagetable on x86_64. */ -finalize_identity_maps ();/* Pick random virtual address starting from LOAD_PHYSICAL_ADDR. */ if (IS_ENABLED (CONFIG_X86_64 ))
Signature · 1 line
2.14.1
PATCH 104/190 gpio: gpio-wcove: fix GPIO IRQ status mask
In reply to Sasha LevinFrom: Kuppuswamy Sathyanarayanan <[email protected]>
[ Upstream commit 881ebd229f4a5ea88f269c1225245e50db9ba303 ]
According to Whiskey Cove PMIC spec, bit 7 of GPIOIRQ0_REG belongs to battery IO. So we should skip this bit when checking for GPIO IRQ pending status. Otherwise, wcove_gpio_irq_handler() might go into the infinite loop until IRQ "pending" status becomes 0. This patch fixes this issue.
--- drivers/gpio/gpio-wcove.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpio/gpio-wcove.c +4 -2
@@ -51,6 +51,8 @@#define GROUP1_NR_IRQS 6#define IRQ_MASK_BASE 0x4e19#define IRQ_STATUS_BASE 0x4e0b +#define GPIO_IRQ0_MASK GENMASK(6, 0) +#define GPIO_IRQ1_MASK GENMASK(5, 0)#define UPDATE_IRQ_TYPE BIT(0)#define UPDATE_IRQ_MASK BIT(1)
@@ -310,7 +312,7 @@ static irqreturn_t wcove_gpio_irq_handler(int irq, void *data)return IRQ_NONE ; } - pending = p[0 ] | (p[1 ] <<8 ); + pending = (p[0 ] &GPIO_IRQ0_MASK ) | ((p[1 ] &GPIO_IRQ1_MASK ) <<7 );if (!pending)return IRQ_NONE ;
@@ -334,7 +336,7 @@ static irqreturn_t wcove_gpio_irq_handler(int irq, void *data)break ; } - pending = p[0 ] | (p[1 ] <<8 ); + pending = (p[0 ] &GPIO_IRQ0_MASK ) | ((p[1 ] &GPIO_IRQ1_MASK ) <<7 ); }return IRQ_HANDLED ;
Signature · 1 line
2.14.1
PATCH 105/190 staging: unisys: visorhba: fix s-Par to boot with option CONFIG_VMAP_STACK set to y
In reply to Sasha LevinFrom: Sameer Wadgaonkar <[email protected]>
[ Upstream commit 3c2bf0bd08123f3497bd3e84bd9088c937b0cb40 ]
The root issue is that we are not allowed to have items on the stack being passed to "DMA" like operations. In this case we have a vmcall and an inline completion of scsi command.
This patch fixes the issue by moving the variables on stack in do_scsi_nolinuxstat() to heap memory.
--- drivers/staging/unisys/visorhba/visorhba_main.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/staging/unisys/visorhba/visorhba_main.c +7 -1
@@ -842,7 +842,7 @@ static void do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct scsi_cmnd *scsicmd) { struct scsi_device *scsidev; -unsigned char buf[36 ]; +unsigned char *buf;struct scatterlist *sg;unsigned int i;char *this_page;
@@ -857,6 +857,10 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct scsi_cmnd *scsicmd)if (cmdrsp->scsi.no_disk_result ==0 )return ; + buf =kzalloc (sizeof (char ) *36 ,GFP_KERNEL ); +if (!buf) +return ; +/* Linux scsi code wants a device at Lun 0 * to issue report luns, but we don't want * a disk there so we'll present a processor
@@ -868,6 +872,7 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct scsi_cmnd *scsicmd)if (scsi_sg_count (scsicmd) ==0 ) {memcpy (scsi_sglist (scsicmd), buf, cmdrsp->scsi.bufflen); +kfree (buf);return ; }
@@ -879,6 +884,7 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct scsi_cmnd *scsicmd)memcpy (this_page, buf + bufind, sg[i].length);kunmap_atomic (this_page_orig); } +kfree (buf); }else { devdata = (struct visorhba_devdata *)scsidev->host->hostdata;for_each_vdisk_match (vdisk, devdata, scsidev) {
Signature · 1 line
2.14.1
PATCH 106/190 staging: wilc1000: fix unchecked return value
In reply to Sasha LevinFrom: Pan Bian <[email protected]>
[ Upstream commit 9e96652756ad647b7bcc03cb99ffc9756d7b5f93 ]
Function dev_alloc_skb() will return a NULL pointer if there is no enough memory. However, in function WILC_WFI_mon_xmit(), its return value is used without validation. This may result in a bad memory access bug. This patch fixes the bug.
--- drivers/staging/wilc1000/linux_mon.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/staging/wilc1000/linux_mon.c +2 -0
@@ -197,6 +197,8 @@ static netdev_tx_t WILC_WFI_mon_xmit(struct sk_buff *skb,if (skb->data[0 ] ==0xc0 && (!(memcmp (broadcast, &skb->data[4 ],6 )))) { skb2 =dev_alloc_skb (skb->len +sizeof (struct wilc_wfi_radiotap_cb_hdr )); +if (!skb2) +return -ENOMEM ;memcpy (skb_put (skb2, skb->len), skb->data, skb->len);
Signature · 1 line
2.14.1
PATCH 107/190 ipvs: explicitly forbid ipv6 service/dest creation if ipv6 mod is disabled
In reply to Sasha LevinFrom: Paolo Abeni <[email protected]>
[ Upstream commit 1442f6f7c1b77de1c508318164a527e240c24a4d ]
When creating a new ipvs service, ipv6 addresses are always accepted if CONFIG_IP_VS_IPV6 is enabled. On dest creation the address family is not explicitly checked.
This allows the user-space to configure ipvs services even if the system is booted with ipv6.disable=1. On specific configuration, ipvs can try to call ipv6 routing code at setup time, causing the kernel to oops due to fib6_rules_ops being NULL.
This change addresses the issue adding a check for the ipv6 module being enabled while validating ipv6 service operations and adding the same validation for dest operations.
According to git history, this issue is apparently present since the introduction of ipv6 support, and the oops can be triggered since commit 09571c7ae30865ad ("IPVS: Add function to determine if IPv6 address is local")
--- net/netfilter/ipvs/ip_vs_ctl.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-)
net/netfilter/ipvs/ip_vs_ctl.c +17 -5
@@ -3092,6 +3092,17 @@ static int ip_vs_genl_dump_services(struct sk_buff *skb,return skb->len; } +static bool ip_vs_is_af_valid (int af) +{ +if (af ==AF_INET ) +return true; +#ifdef CONFIG_IP_VS_IPV6 +if (af ==AF_INET6 &&ipv6_mod_enabled ()) +return true; +#endif +return false; +} + static int ip_vs_genl_parse_service(struct netns_ipvs *ipvs, struct ip_vs_service_user_kern *usvc, struct nlattr *nla, int full_entry,
@@ -3118,11 +3129,7 @@ static int ip_vs_genl_parse_service(struct netns_ipvs *ipvs,memset (usvc,0 ,sizeof (*usvc)); usvc->af =nla_get_u16 (nla_af); -#ifdef CONFIG_IP_VS_IPV6 -if (usvc->af !=AF_INET && usvc->af !=AF_INET6 ) -#else - if (usvc->af != AF_INET) -#endif +if (!ip_vs_is_af_valid (usvc->af))return -EAFNOSUPPORT ;if (nla_fwmark) {
@@ -3624,6 +3631,11 @@ static int ip_vs_genl_set_cmd(struct sk_buff *skb, struct genl_info *info)if (udest.af ==0 ) udest.af = svc->af; +if (!ip_vs_is_af_valid (udest.af)) { + ret = -EAFNOSUPPORT ; + goto out; + } +if (udest.af != svc->af && cmd !=IPVS_CMD_DEL_DEST ) {/* The synchronization protocol is incompatible * with mixed family services
Signature · 1 line
2.14.1
PATCH 108/190 mac80211: Fix possible sband related NULL pointer de-reference
In reply to Sasha LevinFrom: Mohammed Shafi Shajakhan <[email protected]>
[ Upstream commit 21a8e9dd52b64f0170bad208293ef8c30c3c1403 ]
Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even if the channel context configuration is NULL. This crashes for chipsets which support 5 Ghz alone when it tries to access members of 'sband'. Channel context configuration can be NULL in multivif case and when channel switch is in progress (or) when it fails. Fix this by replacing the API 'ieee80211_get_sdata_band' with 'ieee80211_get_sband' which returns a NULL pointer for sband when the channel configuration is NULL.
An example scenario is as below:
In multivif mode (AP + STA) with drivers like ath10k, when we do a channel switch in the AP vif (which has a number of clients connected) and a STA vif which is connected to some other AP, when the channel switch in AP vif fails, while the STA vifs tries to connect to the other AP, there is a window where the channel context is NULL/invalid and this results in a crash while the clients connected to the AP vif tries to reconnect and this race is very similar to the one investigated by Michal in https://patchwork.kernel.org/patch/3788161/ and this does happens with hardware that supports 5Ghz alone after long hours of testing with continuous channel switch on the AP vif
ieee80211 phy0: channel context reservation cannot be finalized because some interfaces aren't switching
wlan0: failed to finalize CSA, disconnecting
wlan0-1: deauthenticating from 8c:fd:f0:01:54:9c by local choice
(Reason: 3=DEAUTH_LEAVING) WARNING: CPU: 1 PID: 19032 at net/mac80211/ieee80211_i.h:1013 sta_info_alloc+0x374/0x3fc [mac80211] [<bf77272c>] (sta_info_alloc [mac80211]) [<bf78776c>] (ieee80211_add_station [mac80211])) [<bf73cc50>] (nl80211_new_station [cfg80211]) Unable to handle kernel NULL pointer dereference at virtual address 00000014 pgd = d5f4c000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM PC is at sta_info_alloc+0x380/0x3fc [mac80211] LR is at sta_info_alloc+0x37c/0x3fc [mac80211] [<bf772738>] (sta_info_alloc [mac80211]) [<bf78776c>] (ieee80211_add_station [mac80211]) [<bf73cc50>] (nl80211_new_station [cfg80211]))
--- net/mac80211/cfg.c | 30 +++++++++++++++++------------- net/mac80211/ibss.c | 6 +++++- net/mac80211/ieee80211_i.h | 36 +++++++++++++++++++++--------------- net/mac80211/mesh.c | 29 ++++++++++++++++++++--------- net/mac80211/mesh_plink.c | 37 ++++++++++++++++++++++++++----------- net/mac80211/mlme.c | 14 ++++++++++++-- net/mac80211/rate.c | 4 +++- net/mac80211/sta_info.c | 13 +++++++++---- net/mac80211/tdls.c | 29 +++++++++++++++++++---------- net/mac80211/tx.c | 5 ++++- net/mac80211/util.c | 6 +++--- 11 files changed, 139 insertions(+), 70 deletions(-)
net/mac80211/cfg.c +17 -13
@@ -620,10 +620,11 @@ void sta_set_rate_info_tx(struct sta_info *sta,int shift =ieee80211_vif_get_shift (&sta->sdata->vif);u16 brate; - sband = sta->local->hw.wiphy->bands[ -ieee80211_get_sdata_band (sta->sdata)]; - brate = sband->bitrates[rate->idx].bitrate; - rinfo->legacy =DIV_ROUND_UP (brate,1 << shift); + sband =ieee80211_get_sband (sta->sdata); +if (sband) { + brate = sband->bitrates[rate->idx].bitrate; + rinfo->legacy =DIV_ROUND_UP (brate,1 << shift); + } }if (rate->flags &IEEE80211_TX_RC_40_MHZ_WIDTH ) rinfo->bw =RATE_INFO_BW_40 ;
@@ -1218,10 +1219,11 @@ static int sta_apply_parameters(struct ieee80211_local *local,int ret =0 ;struct ieee80211_supported_band *sband;struct ieee80211_sub_if_data *sdata = sta->sdata; -enum nl80211_band band =ieee80211_get_sdata_band (sdata);u32 mask, set; - sband = local->hw.wiphy->bands[band]; + sband =ieee80211_get_sband (sdata); +if (!sband) +return -EINVAL ; mask = params->sta_flags_mask; set = params->sta_flags_set;
@@ -1354,7 +1356,7 @@ static int sta_apply_parameters(struct ieee80211_local *local,ieee80211_parse_bitrates (&sdata->vif.bss_conf.chandef, sband, params->supported_rates, params->supported_rates_len, - &sta->sta.supp_rates[band]); + &sta->sta.supp_rates[sband->band]); }if (params->ht_capa)
@@ -1370,8 +1372,8 @@ static int sta_apply_parameters(struct ieee80211_local *local,/* returned value is only needed for rc update, but the * rc isn't initialized here yet, so ignore it */ -__ieee80211_vht_handle_opmode (sdata, sta, - params->opmode_notif, band); +__ieee80211_vht_handle_opmode (sdata, sta, params->opmode_notif, + sband->band); }if (params->support_p2p_ps >=0 )
@@ -2017,13 +2019,15 @@ static int ieee80211_change_bss(struct wiphy *wiphy, struct bss_parameters *params) {struct ieee80211_sub_if_data *sdata =IEEE80211_DEV_TO_SUB_IF (dev); -enum nl80211_band band; +struct ieee80211_supported_band *sband;u32 changed =0 ;if (!sdata_dereference (sdata->u.ap.beacon, sdata))return -ENOENT ; - band =ieee80211_get_sdata_band (sdata); + sband =ieee80211_get_sband (sdata); +if (!sband) +return -EINVAL ;if (params->use_cts_prot >=0 ) { sdata->vif.bss_conf.use_cts_prot = params->use_cts_prot;
@@ -2036,7 +2040,7 @@ static int ieee80211_change_bss(struct wiphy *wiphy, }if (!sdata->vif.bss_conf.use_short_slot && - band ==NL80211_BAND_5GHZ ) { + sband->band ==NL80211_BAND_5GHZ ) { sdata->vif.bss_conf.use_short_slot = true; changed |=BSS_CHANGED_ERP_SLOT ; }
@@ -2049,7 +2053,7 @@ static int ieee80211_change_bss(struct wiphy *wiphy,if (params->basic_rates) {ieee80211_parse_bitrates (&sdata->vif.bss_conf.chandef, - wiphy->bands[band], + wiphy->bands[sband->band], params->basic_rates, params->basic_rates_len, &sdata->vif.bss_conf.basic_rates);
net/mac80211/ibss.c +5 -1
@@ -994,7 +994,7 @@ static void ieee80211_update_sta_info(struct ieee80211_sub_if_data *sdata,enum nl80211_band band = rx_status->band;enum nl80211_bss_scan_width scan_width;struct ieee80211_local *local = sdata->local; -struct ieee80211_supported_band *sband = local->hw.wiphy->bands[band]; +struct ieee80211_supported_band *sband;bool rates_updated = false;u32 supp_rates =0 ;
@@ -1004,6 +1004,10 @@ static void ieee80211_update_sta_info(struct ieee80211_sub_if_data *sdata,if (!ether_addr_equal (mgmt->bssid, sdata->u.ibss.bssid))return ; + sband = local->hw.wiphy->bands[band]; +if (WARN_ON (!sband)) +return ; +rcu_read_lock (); sta =sta_info_get (sdata, mgmt->sa);
net/mac80211/ieee80211_i.h +21 -15
@@ -991,21 +991,6 @@ sdata_assert_lock(struct ieee80211_sub_if_data *sdata)lockdep_assert_held (&sdata->wdev.mtx); } -static inline enum nl80211_band -ieee80211_get_sdata_band (struct ieee80211_sub_if_data *sdata) -{ -enum nl80211_band band =NL80211_BAND_2GHZ ; -struct ieee80211_chanctx_conf *chanctx_conf; - -rcu_read_lock (); - chanctx_conf =rcu_dereference (sdata->vif.chanctx_conf); -if (!WARN_ON (!chanctx_conf)) - band = chanctx_conf->def.chan->band; -rcu_read_unlock (); - -return band; -} -static inline int ieee80211_chandef_get_shift (struct cfg80211_chan_def *chandef) {
@@ -1410,6 +1395,27 @@ IEEE80211_WDEV_TO_SUB_IF(struct wireless_dev *wdev) return container_of(wdev, struct ieee80211_sub_if_data, wdev); } +static inline struct ieee80211_supported_band * +ieee80211_get_sband (struct ieee80211_sub_if_data *sdata) +{ +struct ieee80211_local *local = sdata->local; +struct ieee80211_chanctx_conf *chanctx_conf; +enum nl80211_band band; + +rcu_read_lock (); + chanctx_conf =rcu_dereference (sdata->vif.chanctx_conf); + +if (WARN_ON (!chanctx_conf)) { +rcu_read_unlock (); +return NULL ; + } + + band = chanctx_conf->def.chan->band; +rcu_read_unlock (); + +return local->hw.wiphy->bands[band]; +} +/* this struct represents 802.11n's RA/TID combination */ struct ieee80211_ra_tid {u8 ra[ETH_ALEN ];
net/mac80211/mesh.c +20 -9
@@ -63,6 +63,7 @@ bool mesh_matches_local(struct ieee80211_sub_if_data *sdata,struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;u32 basic_rates =0 ;struct cfg80211_chan_def sta_chan_def; +struct ieee80211_supported_band *sband;/* * As support for each feature is added, check for matching
@@ -83,7 +84,11 @@ bool mesh_matches_local(struct ieee80211_sub_if_data *sdata, (ifmsh->mesh_auth_id == ie->mesh_config->meshconf_auth)))return false; -ieee80211_sta_get_rates (sdata, ie,ieee80211_get_sdata_band (sdata), + sband =ieee80211_get_sband (sdata); +if (!sband) +return false; + +ieee80211_sta_get_rates (sdata, ie, sband->band, &basic_rates);if (sdata->vif.bss_conf.basic_rates != basic_rates)
@@ -399,12 +404,13 @@ static int mesh_add_ds_params_ie(struct ieee80211_sub_if_data *sdata,int mesh_add_ht_cap_ie (struct ieee80211_sub_if_data *sdata,struct sk_buff *skb) { -struct ieee80211_local *local = sdata->local; -enum nl80211_band band =ieee80211_get_sdata_band (sdata);struct ieee80211_supported_band *sband;u8 *pos; - sband = local->hw.wiphy->bands[band]; + sband =ieee80211_get_sband (sdata); +if (!sband) +return -EINVAL ; + if (!sband->ht_cap.ht_supported || sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT || sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_5 ||
@@ -462,12 +468,13 @@ int mesh_add_ht_oper_ie(struct ieee80211_sub_if_data *sdata,int mesh_add_vht_cap_ie (struct ieee80211_sub_if_data *sdata,struct sk_buff *skb) { -struct ieee80211_local *local = sdata->local; -enum nl80211_band band =ieee80211_get_sdata_band (sdata);struct ieee80211_supported_band *sband;u8 *pos; - sband = local->hw.wiphy->bands[band]; + sband =ieee80211_get_sband (sdata); +if (!sband) +return -EINVAL ; + if (!sband->vht_cap.vht_supported || sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT || sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_5 ||
@@ -916,12 +923,16 @@ ieee80211_mesh_process_chnswitch(struct ieee80211_sub_if_data *sdata,struct cfg80211_csa_settings params;struct ieee80211_csa_ie csa_ie;struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh; -enum nl80211_band band =ieee80211_get_sdata_band (sdata); +struct ieee80211_supported_band *sband;int err;u32 sta_flags;sdata_assert_lock (sdata); + sband =ieee80211_get_sband (sdata); +if (!sband) +return false; + sta_flags =IEEE80211_STA_DISABLE_VHT ;switch (sdata->vif.bss_conf.chandef.width) {case NL80211_CHAN_WIDTH_20_NOHT :
@@ -935,7 +946,7 @@ ieee80211_mesh_process_chnswitch(struct ieee80211_sub_if_data *sdata,memset (¶ms,0 ,sizeof (params));memset (&csa_ie,0 ,sizeof (csa_ie)); - err =ieee80211_parse_ch_switch_ie (sdata, elems, band, + err =ieee80211_parse_ch_switch_ie (sdata, elems, sband->band, sta_flags, sdata->vif.addr, &csa_ie);if (err <0 )
net/mac80211/mesh_plink.c +26 -11
@@ -93,19 +93,23 @@ static inline void mesh_plink_fsm_restart(struct sta_info *sta)static u32 mesh_set_short_slot_time (struct ieee80211_sub_if_data *sdata) {struct ieee80211_local *local = sdata->local; -enum nl80211_band band =ieee80211_get_sdata_band (sdata); -struct ieee80211_supported_band *sband = local->hw.wiphy->bands[band]; +struct ieee80211_supported_band *sband;struct sta_info *sta;u32 erp_rates =0 , changed =0 ;int i;bool short_slot = false; -if (band ==NL80211_BAND_5GHZ ) { + sband =ieee80211_get_sband (sdata); +if (!sband) +return changed; + +if (sband->band ==NL80211_BAND_5GHZ ) {/* (IEEE 802.11-2012 19.4.5) */ short_slot = true; goto out; - }else if (band !=NL80211_BAND_2GHZ ) + }else if (sband->band !=NL80211_BAND_2GHZ ) { goto out; + }for (i =0 ; i < sband->n_bitrates; i++)if (sband->bitrates[i].flags &IEEE80211_RATE_ERP_G )
@@ -121,7 +125,7 @@ static u32 mesh_set_short_slot_time(struct ieee80211_sub_if_data *sdata)continue ; short_slot = false; -if (erp_rates & sta->sta.supp_rates[band]) +if (erp_rates & sta->sta.supp_rates[sband->band]) short_slot = true;else break ;
@@ -247,7 +251,15 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata, mgmt->u.action.u.self_prot.action_code = action;if (action !=WLAN_SP_MESH_PEERING_CLOSE ) { -enum nl80211_band band =ieee80211_get_sdata_band (sdata); +struct ieee80211_supported_band *sband; +enum nl80211_band band; + + sband =ieee80211_get_sband (sdata); +if (!sband) { + err = -EINVAL ; + goto free; + } + band = sband->band;/* capability info */ pos =skb_put (skb,2 );
@@ -393,13 +405,16 @@ static void mesh_sta_info_init(struct ieee80211_sub_if_data *sdata, struct ieee802_11_elems *elems, bool insert) {struct ieee80211_local *local = sdata->local; -enum nl80211_band band =ieee80211_get_sdata_band (sdata);struct ieee80211_supported_band *sband;u32 rates, basic_rates =0 , changed =0 ;enum ieee80211_sta_rx_bandwidth bw = sta->sta.bandwidth; - sband = local->hw.wiphy->bands[band]; - rates =ieee80211_sta_get_rates (sdata, elems, band, &basic_rates); + sband =ieee80211_get_sband (sdata); +if (!sband) +return ; + + rates =ieee80211_sta_get_rates (sdata, elems, sband->band, + &basic_rates);spin_lock_bh (&sta->mesh->plink_lock); sta->rx_stats.last_rx = jiffies;
@@ -410,9 +425,9 @@ static void mesh_sta_info_init(struct ieee80211_sub_if_data *sdata, goto out; sta->mesh->processed_beacon = true; -if (sta->sta.supp_rates[band] != rates) +if (sta->sta.supp_rates[sband->band] != rates) changed |=IEEE80211_RC_SUPP_RATES_CHANGED ; - sta->sta.supp_rates[band] = rates; + sta->sta.supp_rates[sband->band] = rates;if (ieee80211_ht_cap_ie_to_sta_ht_cap (sdata, sband, elems->ht_cap_elem, sta))
net/mac80211/mlme.c +12 -2
@@ -1851,11 +1851,16 @@ static u32 ieee80211_handle_bss_capability(struct ieee80211_sub_if_data *sdata, u16 capab, bool erp_valid, u8 erp) { struct ieee80211_bss_conf *bss_conf = &sdata->vif.bss_conf; +struct ieee80211_supported_band *sband;u32 changed =0 ;bool use_protection;bool use_short_preamble;bool use_short_slot; + sband =ieee80211_get_sband (sdata); +if (!sband) +return changed; +if (erp_valid) { use_protection = (erp &WLAN_ERP_USE_PROTECTION ) !=0 ; use_short_preamble = (erp &WLAN_ERP_BARKER_PREAMBLE ) ==0 ;
@@ -1865,7 +1870,7 @@ static u32 ieee80211_handle_bss_capability(struct ieee80211_sub_if_data *sdata, } use_short_slot = !!(capab &WLAN_CAPABILITY_SHORT_SLOT_TIME ); -if (ieee80211_get_sdata_band (sdata) ==NL80211_BAND_5GHZ ) +if (sband->band ==NL80211_BAND_5GHZ ) use_short_slot = true;if (use_protection != bss_conf->use_cts_prot) {
@@ -2994,7 +2999,12 @@ static bool ieee80211_assoc_success(struct ieee80211_sub_if_data *sdata, goto out; } - sband = local->hw.wiphy->bands[ieee80211_get_sdata_band (sdata)]; + sband =ieee80211_get_sband (sdata); +if (!sband) { +mutex_unlock (&sdata->local->sta_mtx); + ret = false; + goto out; + }/* Set up internal HT/VHT capabilities */ if (elems.ht_cap_elem && !(ifmgd->flags &IEEE80211_STA_DISABLE_HT ))
net/mac80211/rate.c +3 -1
@@ -875,7 +875,9 @@ int rate_control_set_rates(struct ieee80211_hw *hw,struct ieee80211_sta_rates *old;struct ieee80211_supported_band *sband; - sband = hw->wiphy->bands[ieee80211_get_sdata_band (sta->sdata)]; + sband =ieee80211_get_sband (sta->sdata); +if (!sband) +return -EINVAL ;rate_control_apply_mask_ratetbl (sta, sband, rates);/* * mac80211 guarantees that this function will not be called
net/mac80211/sta_info.c +9 -4
@@ -395,10 +395,15 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata, sta->sta.smps_mode =IEEE80211_SMPS_OFF ;if (sdata->vif.type ==NL80211_IFTYPE_AP || sdata->vif.type ==NL80211_IFTYPE_AP_VLAN ) { -struct ieee80211_supported_band *sband = - hw->wiphy->bands[ieee80211_get_sdata_band (sdata)]; -u8 smps = (sband->ht_cap.cap &IEEE80211_HT_CAP_SM_PS ) >> -IEEE80211_HT_CAP_SM_PS_SHIFT ; +struct ieee80211_supported_band *sband; +u8 smps; + + sband =ieee80211_get_sband (sdata); +if (!sband) + goto free_txq; + + smps = (sband->ht_cap.cap &IEEE80211_HT_CAP_SM_PS ) >> +IEEE80211_HT_CAP_SM_PS_SHIFT ;/* * Assume that hostapd advertises our caps in the beacon and * this is the known_smps_mode for a station that just assciated
net/mac80211/tdls.c +19 -10
@@ -47,8 +47,7 @@ static void ieee80211_tdls_add_ext_capab(struct ieee80211_sub_if_data *sdata,NL80211_FEATURE_TDLS_CHANNEL_SWITCH ;bool wider_band =ieee80211_hw_check (&local->hw,TDLS_WIDER_BW ) && !ifmgd->tdls_wider_bw_prohibited; -enum nl80211_band band =ieee80211_get_sdata_band (sdata); -struct ieee80211_supported_band *sband = local->hw.wiphy->bands[band]; +struct ieee80211_supported_band *sband =ieee80211_get_sband (sdata);bool vht = sband && sband->vht_cap.vht_supported;u8 *pos = (void *)skb_put (skb,10 );
@@ -180,11 +179,14 @@ static void ieee80211_tdls_add_bss_coex_ie(struct sk_buff *skb)static u16 ieee80211_get_tdls_sta_capab (struct ieee80211_sub_if_data *sdata,u16 status_code) { +struct ieee80211_supported_band *sband; +/* The capability will be 0 when sending a failure code */ if (status_code !=0 )return 0 ; -if (ieee80211_get_sdata_band (sdata) ==NL80211_BAND_2GHZ ) { + sband =ieee80211_get_sband (sdata); +if (sband && sband->band ==NL80211_BAND_2GHZ ) {return WLAN_CAPABILITY_SHORT_SLOT_TIME |WLAN_CAPABILITY_SHORT_PREAMBLE ; }
@@ -358,17 +360,20 @@ ieee80211_tdls_add_setup_start_ies(struct ieee80211_sub_if_data *sdata, u8 action_code, bool initiator, const u8 *extra_ies, size_t extra_ies_len) { - enum nl80211_band band = ieee80211_get_sdata_band(sdata); -struct ieee80211_local *local = sdata->local; struct ieee80211_supported_band *sband; +struct ieee80211_local *local = sdata->local;struct ieee80211_sta_ht_cap ht_cap;struct ieee80211_sta_vht_cap vht_cap;struct sta_info *sta =NULL ;size_t offset =0 , noffset;u8 *pos; -ieee80211_add_srates_ie (sdata, skb, false, band); -ieee80211_add_ext_srates_ie (sdata, skb, false, band); + sband =ieee80211_get_sband (sdata); +if (!sband) +return ; + +ieee80211_add_srates_ie (sdata, skb, false, sband->band); +ieee80211_add_ext_srates_ie (sdata, skb, false, sband->band);ieee80211_tdls_add_supp_channels (sdata, skb);/* add any custom IEs that go before Extended Capabilities */
@@ -439,7 +444,6 @@ ieee80211_tdls_add_setup_start_ies(struct ieee80211_sub_if_data *sdata,* the same on all bands. The specification limits the setup to a * single HT-cap, so use the current band for now. */ - sband = local->hw.wiphy->bands[band];memcpy (&ht_cap, &sband->ht_cap,sizeof (ht_cap)); if ((action_code == WLAN_TDLS_SETUP_REQUEST ||
@@ -545,9 +549,13 @@ ieee80211_tdls_add_setup_cfm_ies(struct ieee80211_sub_if_data *sdata,struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;size_t offset =0 , noffset;struct sta_info *sta, *ap_sta; -enum nl80211_band band =ieee80211_get_sdata_band (sdata); +struct ieee80211_supported_band *sband;u8 *pos; + sband =ieee80211_get_sband (sdata); +if (!sband) +return ; +mutex_lock (&local->sta_mtx); sta =sta_info_get (sdata, peer);
@@ -612,7 +620,8 @@ ieee80211_tdls_add_setup_cfm_ies(struct ieee80211_sub_if_data *sdata,ieee80211_tdls_add_link_ie (sdata, skb, peer, initiator);/* only include VHT-operation if not on the 2.4GHz band */ -if (band !=NL80211_BAND_2GHZ && sta->sta.vht_cap.vht_supported) { +if (sband->band !=NL80211_BAND_2GHZ && + sta->sta.vht_cap.vht_supported) {/* * if both peers support WIDER_BW, we can expand the chandef to * a wider compatible one, up to 80MHz
net/mac80211/tx.c +4 -1
@@ -4182,7 +4182,10 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,return bcn; shift =ieee80211_vif_get_shift (vif); - sband = hw->wiphy->bands[ieee80211_get_sdata_band (vif_to_sdata (vif))]; + sband =ieee80211_get_sband (vif_to_sdata (vif)); +if (!sband) +return bcn; +ieee80211_tx_monitor (hw_to_local (hw), copy, sband,1 , shift, false);return bcn;
net/mac80211/util.c +3 -3
@@ -1590,14 +1590,14 @@ u32 ieee80211_sta_get_rates(struct ieee80211_sub_if_data *sdata,size_t num_rates;u32 supp_rates, rate_flags;int i, j, shift; + sband = sdata->local->hw.wiphy->bands[band]; +if (WARN_ON (!sband)) +return 1 ; rate_flags =ieee80211_chandef_rate_flags (&sdata->vif.bss_conf.chandef); shift =ieee80211_vif_get_shift (&sdata->vif); -if (WARN_ON (!sband)) -return 1 ; - num_rates = sband->n_bitrates; supp_rates =0 ; for (i = 0; i < elems->supp_rates_len +
Signature · 1 line
2.14.1
PATCH 109/190 mmc: sdhci-of-esdhc: limit SD clock for ls1012a/ls1046a
In reply to Sasha LevinFrom: yangbo lu <[email protected]>
[ Upstream commit a627f025eb0534052ff451427c16750b3530634c ]
The ls1046a datasheet specified that the max SD clock frequency for eSDHC SDR104/HS200 was 167MHz, and the ls1012a datasheet specified it's 125MHz for ls1012a. So this patch is to add the limitation.
--- drivers/mmc/host/sdhci-of-esdhc.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/mmc/host/sdhci-of-esdhc.c +14 -0
@@ -432,6 +432,20 @@ static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock)if (esdhc->vendor_ver <VENDOR_V_23 ) pre_div =2 ; +/* +* Limit SD clock to 167MHz for ls1046a according to its datasheet +*/ +if (clock >167000000 && +of_find_compatible_node (NULL ,NULL ,"fsl,ls1046a-esdhc" )) + clock =167000000 ; + +/* +* Limit SD clock to 125MHz for ls1012a according to its datasheet +*/ +if (clock >125000000 && +of_find_compatible_node (NULL ,NULL ,"fsl,ls1012a-esdhc" )) + clock =125000000 ; +/* Workaround to reduce the clock frequency for p1010 esdhc */ if (of_find_compatible_node (NULL ,NULL ,"fsl,p1010-esdhc" )) {if (clock >20000000 )
Signature · 1 line
2.14.1
PATCH 110/190 netfilter: x_tables: unlock on error in xt_find_table_lock()
In reply to Sasha LevinFrom: Dan Carpenter <[email protected]>
[ Upstream commit 7dde07e9c53617549d67dd3e1d791496d0d3868e ]
According to my static checker we should unlock here before the return. That seems reasonable to me as well.
Fixes" b9e69e127397 ("netfilter: xtables: don't hook tables by default")
--- net/netfilter/x_tables.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/netfilter/x_tables.c +3 -1
@@ -1004,8 +1004,10 @@ struct xt_table *xt_find_table_lock(struct net *net, u_int8_t af,list_for_each_entry (t, &init_net.xt.tables[af], list) {if (strcmp (t->name, name))continue ; -if (!try_module_get (t->me)) +if (!try_module_get (t->me)) { +mutex_unlock (&xt[af].mutex);return NULL ; + }mutex_unlock (&xt[af].mutex);if (t->table_init (net) !=0 ) {
Signature · 1 line
2.14.1
PATCH 111/190 ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
In reply to Sasha LevinFrom: Kishon Vijay Abraham I <[email protected]>
[ Upstream commit 2c949ce38f4e81d7487f165fa3b8f77d74a2a6c4 ]
The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO in RC mode. However in EP mode, the host system is not able to access the MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.
--- arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-omap2/clockdomains7xx_data.c +1 -1
@@ -524,7 +524,7 @@ static struct clockdomain pcie_7xx_clkdm = { .dep_bit = DRA7XX_PCIE_STATDEP_SHIFT, .wkdep_srcs = pcie_wkup_sleep_deps, .sleepdep_srcs = pcie_wkup_sleep_deps, - .flags = CLKDM_CAN_HWSUP_SWSUP, + .flags = CLKDM_CAN_SWSUP, };static struct clockdomain atl_7xx_clkdm = {
Signature · 1 line
2.14.1
PATCH 112/190 IB/rdmavt: restore IRQs on error path in rvt_create_ah()
In reply to Sasha LevinFrom: Dan Carpenter <[email protected]>
[ Upstream commit f0bb2d44ca26b7090dc7bade8877b77005f07dfc ]
We need to call spin_unlock_irqrestore() instead of vanilla spin_unlock() on this error path.
--- drivers/infiniband/sw/rdmavt/ah.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/sw/rdmavt/ah.c +1 -1
@@ -119,7 +119,7 @@ struct ib_ah *rvt_create_ah(struct ib_pd *pd,spin_lock_irqsave (&dev->n_ahs_lock, flags);if (dev->n_ahs_allocated == dev->dparms.props.max_ah) { -spin_unlock (&dev->n_ahs_lock); +spin_unlock_irqrestore (&dev->n_ahs_lock, flags);kfree (ah);return ERR_PTR (-ENOMEM ); }
Signature · 1 line
2.14.1
PATCH 113/190 IB/hfi1: Fix softlockup issue
In reply to Sasha LevinFrom: Tadeusz Struk <[email protected]>
[ Upstream commit 22546b741af8355cd2e16739b6af4a8f17081839 ]
Soft lockups can occur because the mad processing on different CPUs acquire the spin lock dc8051_lock:
[534552.835870] [<ffffffffa026f993>] ? read_dev_port_cntr.isra.37+0x23/0x160 [hfi1] [534552.835880] [<ffffffffa02775af>] read_dev_cntr+0x4f/0x60 [hfi1] [534552.835893] [<ffffffffa028d7cd>] pma_get_opa_portstatus+0x64d/0x8c0 [hfi1] [534552.835904] [<ffffffffa0290e7d>] hfi1_process_mad+0x48d/0x18c0 [hfi1] [534552.835908] [<ffffffff811dc1f1>] ? __slab_free+0x81/0x2f0 [534552.835936] [<ffffffffa024c34e>] ? ib_mad_recv_done+0x21e/0xa30 [ib_core] [534552.835939] [<ffffffff811dd153>] ? __kmalloc+0x1f3/0x240 [534552.835947] [<ffffffffa024c3fb>] ib_mad_recv_done+0x2cb/0xa30 [ib_core] [534552.835955] [<ffffffffa0237c85>] __ib_process_cq+0x55/0xd0 [ib_core] [534552.835962] [<ffffffffa0237d70>] ib_cq_poll_work+0x20/0x60 [ib_core] [534552.835964] [<ffffffff810a7f3b>] process_one_work+0x17b/0x470 [534552.835966] [<ffffffff810a8d76>] worker_thread+0x126/0x410 [534552.835969] [<ffffffff810a8c50>] ? rescuer_thread+0x460/0x460 [534552.835971] [<ffffffff810b052f>] kthread+0xcf/0xe0 [534552.835974] [<ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140 [534552.835977] [<ffffffff81696418>] ret_from_fork+0x58/0x90 [534552.835980] [<ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140
This issue is made worse when the 8051 is busy and the reads take longer. Fix by using a non-spinning lock procure.
--- drivers/infiniband/hw/hfi1/chip.c | 86 +++++++++++++++++++++++---------------- drivers/infiniband/hw/hfi1/hfi.h | 7 ++-- drivers/infiniband/hw/hfi1/init.c | 2 +- 3 files changed, 57 insertions(+), 38 deletions(-)
drivers/infiniband/hw/hfi1/chip.c +52 -34
@@ -6379,18 +6379,17 @@ static void lcb_shutdown(struct hfi1_devdata *dd, int abort)* * The expectation is that the caller of this routine would have taken * care of properly transitioning the link into the correct state. +* NOTE: the caller needs to acquire the dd->dc8051_lock lock +* before calling this function. */ -static void dc_shutdown (struct hfi1_devdata *dd) +static void _dc_shutdown (struct hfi1_devdata *dd) { -unsigned long flags; +lockdep_assert_held (&dd->dc8051_lock); -spin_lock_irqsave (&dd->dc8051_lock, flags); -if (dd->dc_shutdown) { -spin_unlock_irqrestore (&dd->dc8051_lock, flags); +if (dd->dc_shutdown)return ; - } + dd->dc_shutdown =1 ; -spin_unlock_irqrestore (&dd->dc8051_lock, flags);/* Shutdown the LCB */ lcb_shutdown (dd,1 );/*
@@ -6401,35 +6400,45 @@ static void dc_shutdown(struct hfi1_devdata *dd)write_csr (dd,DC_DC8051_CFG_RST ,0x1 ); } +static void dc_shutdown (struct hfi1_devdata *dd) +{ +mutex_lock (&dd->dc8051_lock); +_dc_shutdown (dd); +mutex_unlock (&dd->dc8051_lock); +} +/* * Calling this after the DC has been brought out of reset should not * do any damage. +* NOTE: the caller needs to acquire the dd->dc8051_lock lock +* before calling this function. */ -static void dc_start (struct hfi1_devdata *dd) +static void _dc_start (struct hfi1_devdata *dd) { -unsigned long flags; -int ret; +lockdep_assert_held (&dd->dc8051_lock); -spin_lock_irqsave (&dd->dc8051_lock, flags);if (!dd->dc_shutdown) - goto done; -spin_unlock_irqrestore (&dd->dc8051_lock, flags); +return ; +/* Take the 8051 out of reset */ write_csr (dd,DC_DC8051_CFG_RST ,0ull );/* Wait until 8051 is ready */ - ret =wait_fm_ready (dd,TIMEOUT_8051_START ); -if (ret) { +if (wait_fm_ready (dd,TIMEOUT_8051_START ))dd_dev_err (dd,"%s: timeout starting 8051 firmware\n" , __func__); - } +/* Take away reset for LCB and RX FPE (set in lcb_shutdown). */ write_csr (dd,DCC_CFG_RESET ,0x10 );/* lcb_shutdown() with abort=1 does not restore these */ write_csr (dd,DC_LCB_ERR_EN , dd->lcb_err_en); -spin_lock_irqsave (&dd->dc8051_lock, flags); dd->dc_shutdown =0 ; -done: -spin_unlock_irqrestore (&dd->dc8051_lock, flags); +} + +static void dc_start (struct hfi1_devdata *dd) +{ +mutex_lock (&dd->dc8051_lock); +_dc_start (dd); +mutex_unlock (&dd->dc8051_lock); }/*
@@ -8418,16 +8427,11 @@ static int do_8051_command( {u64 reg, completed;int return_code; -unsigned long flags;unsigned long timeout;hfi1_cdbg (DC8051 ,"type %d, data 0x%012llx" , type, in_data); -/* -* Alternative to holding the lock for a long time: -* - keep busy wait - have other users bounce off -*/ -spin_lock_irqsave (&dd->dc8051_lock, flags); +mutex_lock (&dd->dc8051_lock);/* We can't send any commands to the 8051 if it's in reset */ if (dd->dc_shutdown) {
@@ -8453,10 +8457,8 @@ static int do_8051_command( return_code = -ENXIO ; goto fail; } -spin_unlock_irqrestore (&dd->dc8051_lock, flags); -dc_shutdown (dd); -dc_start (dd); -spin_lock_irqsave (&dd->dc8051_lock, flags); +_dc_shutdown (dd); +_dc_start (dd); }/*
@@ -8534,8 +8536,7 @@ static int do_8051_command(write_csr (dd,DC_DC8051_CFG_HOST_CMD_0 ,0 ); fail: -spin_unlock_irqrestore (&dd->dc8051_lock, flags); - +mutex_unlock (&dd->dc8051_lock);return return_code; }
@@ -11846,6 +11847,10 @@ static void free_cntrs(struct hfi1_devdata *dd) dd->scntrs =NULL ;kfree (dd->cntrnames); dd->cntrnames =NULL ; +if (dd->update_cntr_wq) { +destroy_workqueue (dd->update_cntr_wq); + dd->update_cntr_wq =NULL ; + } } static u64 read_dev_port_cntr(struct hfi1_devdata *dd, struct cntr_entry *entry,
@@ -12001,7 +12006,7 @@ u64 write_port_cntr(struct hfi1_pportdata *ppd, int index, int vl, u64 data)return write_dev_port_cntr (ppd->dd, entry, sval, ppd, vl, data); } -static void update_synth_timer (unsigned long opaque) +static void do_update_synth_timer (struct work_struct *work) {u64 cur_tx;u64 cur_rx;
@@ -12010,8 +12015,8 @@ static void update_synth_timer(unsigned long opaque)int i, j, vl;struct hfi1_pportdata *ppd;struct cntr_entry *entry; - -struct hfi1_devdata *dd = (struct hfi1_devdata *)opaque; + struct hfi1_devdata *dd = container_of(work, struct hfi1_devdata, + update_cntr_work);/* * Rather than keep beating on the CSRs pick a minimal set that we can
@@ -12094,7 +12099,13 @@ static void update_synth_timer(unsigned long opaque) }else {hfi1_cdbg (CNTR ,"[%d] No update necessary" , dd->unit); } +} + +static void update_synth_timer (unsigned long opaque) +{ +struct hfi1_devdata *dd = (struct hfi1_devdata *)opaque; +queue_work (dd->update_cntr_wq, &dd->update_cntr_work);mod_timer (&dd->synth_stats_timer, jiffies +HZ *SYNTH_CNT_TIME ); }
@@ -12330,6 +12341,13 @@ static int init_cntrs(struct hfi1_devdata *dd)if (init_cpu_counters (dd)) goto bail; + dd->update_cntr_wq =alloc_ordered_workqueue ("hfi1_update_cntr_%d" , +WQ_MEM_RECLAIM , dd->unit); +if (!dd->update_cntr_wq) + goto bail; + +INIT_WORK (&dd->update_cntr_work, do_update_synth_timer); +mod_timer (&dd->synth_stats_timer, jiffies +HZ *SYNTH_CNT_TIME );return 0 ; bail:
drivers/infiniband/hw/hfi1/hfi.h +4 -3
@@ -475,7 +475,7 @@ struct rvt_sge_state;#define HFI1_PART_ENFORCE_OUT 0x2/* how often we check for synthetic counter wrap around */ -#define SYNTH_CNT_TIME 2 +#define SYNTH_CNT_TIME 3/* Counter flags */ #define CNTR_NORMAL 0x0/* Normal counters, just read register */
@@ -929,8 +929,9 @@ struct hfi1_devdata {spinlock_t rcvctrl_lock;/* protect changes to RcvCtrl */ /* around rcd and (user ctxts) ctxt_cnt use (intr vs free) */ spinlock_t uctxt_lock;/* rcd and user context changes */ -/* exclusive access to 8051 */ -spinlock_t dc8051_lock; +struct mutex dc8051_lock;/* exclusive access to 8051 */ +struct workqueue_struct *update_cntr_wq; +struct work_struct update_cntr_work;/* exclusive access to 8051 memory */ spinlock_t dc8051_memlock;int dc8051_timed_out;/* remember if the 8051 timed out */
drivers/infiniband/hw/hfi1/init.c +1 -1
@@ -1078,11 +1078,11 @@ struct hfi1_devdata *hfi1_alloc_devdata(struct pci_dev *pdev, size_t extra)spin_lock_init (&dd->uctxt_lock);spin_lock_init (&dd->hfi1_diag_trans_lock);spin_lock_init (&dd->sc_init_lock); -spin_lock_init (&dd->dc8051_lock);spin_lock_init (&dd->dc8051_memlock);seqlock_init (&dd->sc2vl_lock);spin_lock_init (&dd->sde_map_lock);spin_lock_init (&dd->pio_map_lock); +mutex_init (&dd->dc8051_lock);init_waitqueue_head (&dd->event_queue); dd->int_counter =alloc_percpu (u64);
Signature · 1 line
2.14.1
PATCH 114/190 platform/x86: asus-wmi: try to set als by default
In reply to Sasha LevinFrom: Oleksij Rempel <[email protected]>
[ Upstream commit e9b615186805e2c18a0ac76aca62c1543ecfdbb8 ]
some laptops, for example ASUS UX330UAK, have brocken als_get function but working als_set funktion. In this case, ALS will stay turned off.
Method (WMNB, 3, Serialized)
{
...
If (Local0 == 0x53545344)
{
...
If (IIA0 == 0x00050001)
{
If (!ALSP)
{
Return (0x02)
}
Local0 = (GALS & 0x10) <<<---- bug,
should be: (GALS () & 0x10)
If (Local0)
{
Return (0x00050001)
}
Else
{
Return (0x00050000)
}
}
.....
If (Local0 == 0x53564544)
{
...
If (IIA0 == 0x00050001)
{
Return (ALSC (IIA1))
}
......
Method (GALS, 0, NotSerialized)
{
Local0 = Zero
Local0 |= 0x20
If (ALAE)
{
Local0 |= 0x10
}
Local1 = 0x0A
Local1 <<= 0x08
Local0 |= Local1
Return (Local0)
}Since it works without problems on Windows I assume ASUS WMI driver for Win never trying to get ALS state, and instead it is setting it by default to ON.
This patch will do the same. Turn ALS on by default.
--- drivers/platform/x86/asus-nb-wmi.c | 13 +++++++++++++ drivers/platform/x86/asus-wmi.c | 12 ++++++++++++ drivers/platform/x86/asus-wmi.h | 1 + 3 files changed, 26 insertions(+)
drivers/platform/x86/asus-nb-wmi.c +13 -0
@@ -120,6 +120,10 @@ static struct quirk_entry quirk_asus_x550lb = { .xusb2pr = 0x01D9, }; +static struct quirk_entry quirk_asus_ux330uak = { + .wmi_force_als_set = true, +}; +static int dmi_matched (const struct dmi_system_id *dmi) { quirks = dmi->driver_data;
@@ -420,6 +424,15 @@ static const struct dmi_system_id asus_quirks[] = { }, .driver_data = &quirk_asus_ux303ub, }, + { + .callback = dmi_matched, + .ident = "ASUSTeK COMPUTER INC. UX330UAK", + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK COMPUTER INC." ), + DMI_MATCH(DMI_PRODUCT_NAME, "UX330UAK"), + }, + .driver_data = &quirk_asus_ux330uak, + }, { .callback = dmi_matched, .ident = "ASUSTeK COMPUTER INC. X550LB",
drivers/platform/x86/asus-wmi.c +12 -0
@@ -1108,6 +1108,15 @@ static void asus_wmi_set_xusb2pr(struct asus_wmi *asus) orig_ports_available, ports_available); } +/* +* Some devices dont support or have borcken get_als method +* but still support set method. +*/ +static void asus_wmi_set_als (void ) +{ +asus_wmi_set_devstate (ASUS_WMI_DEVID_ALS_ENABLE ,1 ,NULL ); +} +/* * Hwmon device */
@@ -2120,6 +2129,9 @@ static int asus_wmi_add(struct platform_device *pdev) goto fail_rfkill; } +if (asus->driver->quirks->wmi_force_als_set) +asus_wmi_set_als (); +/* Some Asus desktop boards export an acpi-video backlight interface, stop this from showing up */ chassis_type =dmi_get_system_info (DMI_CHASSIS_TYPE );
drivers/platform/x86/asus-wmi.h +1 -0
@@ -45,6 +45,7 @@ struct quirk_entry {bool store_backlight_power;bool wmi_backlight_power;bool wmi_backlight_native; +bool wmi_force_als_set;int wapf;/* * For machines with AMD graphic chips, it will send out WMI event
Signature · 1 line
2.14.1
PATCH 115/190 ipmi/watchdog: fix wdog hang on panic waiting for ipmi response
In reply to Sasha LevinFrom: Robert Lippert <[email protected]>
[ Upstream commit 2c1175c2e8e5487233cabde358a19577562ac83e ]
Commit c49c097610fe ("ipmi: Don't call receive handler in the panic context") means that the panic_recv_free is not called during a panic and the atomic count does not drop to 0.
Fix this by only expecting one decrement of the atomic variable which comes from panic_smi_free.
--- drivers/char/ipmi/ipmi_watchdog.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/char/ipmi/ipmi_watchdog.c +4 -4
@@ -515,7 +515,7 @@ static void panic_halt_ipmi_heartbeat(void) msg.cmd =IPMI_WDOG_RESET_TIMER ; msg.data =NULL ; msg.data_len =0 ; -atomic_add (2 , &panic_done_count); +atomic_add (1 , &panic_done_count); rv = ipmi_request_supply_msgs(watchdog_user, (struct ipmi_addr *) &addr, 0,
@@ -525,7 +525,7 @@ static void panic_halt_ipmi_heartbeat(void) &panic_halt_heartbeat_recv_msg, 1);if (rv) -atomic_sub (2 , &panic_done_count); +atomic_sub (1 , &panic_done_count); }static struct ipmi_smi_msg panic_halt_smi_msg = {
@@ -549,12 +549,12 @@ static void panic_halt_ipmi_set_timeout(void)/* Wait for the messages to be free. */ while (atomic_read (&panic_done_count) !=0 )ipmi_poll_interface (watchdog_user); -atomic_add (2 , &panic_done_count); +atomic_add (1 , &panic_done_count); rv =i_ipmi_set_timeout (&panic_halt_smi_msg, &panic_halt_recv_msg, &send_heartbeat_now);if (rv) { -atomic_sub (2 , &panic_done_count); +atomic_sub (1 , &panic_done_count); printk(KERN_WARNING PFX "Unable to extend the watchdog timeout."); }else {
Signature · 1 line
2.14.1
PATCH 116/190 ACPI / PMIC: xpower: Fix power_table addresses
In reply to Sasha LevinFrom: Hans de Goede <[email protected]>
[ Upstream commit 2bde7c32b1db162692f05c6be066b5bcd3d9fdbe ]
The power table addresses should be contiguous, but there was a hole where 0x34 was missing. On most devices this is not a problem as addresses above 0x34 are used for the BUC# convertors which are not used in the DSDTs I've access to but after the BUC# convertors there is a field named GPI1 in the DSTDs, which does get used in some cases and ended up turning BUC6 on and off due to the wrong addresses, resulting in turning the entire device off (or causing it to reboot).
Removing the hole in the addresses fixes this, fixing one of my Bay Trail tablets turning off while booting the mainline kernel.
While at it add comments with the field names used in the DSDTs to make it easier to compare the register and bits used at each address with the datasheet.
--- drivers/acpi/pmic/intel_pmic_xpower.c | 50 +++++++++++++++++------------------ 1 file changed, 25 insertions(+), 25 deletions(-)
drivers/acpi/pmic/intel_pmic_xpower.c +25 -25
@@ -28,97 +28,97 @@ static struct pmic_table power_table[] = { .address = 0x00, .reg = 0x13, .bit = 0x05, - }, + }, /* ALD1 */ { .address = 0x04, .reg = 0x13, .bit = 0x06, - }, + }, /* ALD2 */ { .address = 0x08, .reg = 0x13, .bit = 0x07, - }, + }, /* ALD3 */ { .address = 0x0c, .reg = 0x12, .bit = 0x03, - }, + }, /* DLD1 */ { .address = 0x10, .reg = 0x12, .bit = 0x04, - }, + }, /* DLD2 */ { .address = 0x14, .reg = 0x12, .bit = 0x05, - }, + }, /* DLD3 */ { .address = 0x18, .reg = 0x12, .bit = 0x06, - }, + }, /* DLD4 */ { .address = 0x1c, .reg = 0x12, .bit = 0x00, - }, + }, /* ELD1 */ { .address = 0x20, .reg = 0x12, .bit = 0x01, - }, + }, /* ELD2 */ { .address = 0x24, .reg = 0x12, .bit = 0x02, - }, + }, /* ELD3 */ { .address = 0x28, .reg = 0x13, .bit = 0x02, - }, + }, /* FLD1 */ { .address = 0x2c, .reg = 0x13, .bit = 0x03, - }, + }, /* FLD2 */ { .address = 0x30, .reg = 0x13, .bit = 0x04, - }, + }, /* FLD3 */ { - .address = 0x38, + .address = 0x34, .reg = 0x10, .bit = 0x03, - }, + }, /* BUC1 */ { - .address = 0x3c, + .address = 0x38, .reg = 0x10, .bit = 0x06, - }, + }, /* BUC2 */ { - .address = 0x40, + .address = 0x3c, .reg = 0x10, .bit = 0x05, - }, + }, /* BUC3 */ { - .address = 0x44, + .address = 0x40, .reg = 0x10, .bit = 0x04, - }, + }, /* BUC4 */ { - .address = 0x48, + .address = 0x44, .reg = 0x10, .bit = 0x01, - }, + }, /* BUC5 */ { - .address = 0x4c, + .address = 0x48, .reg = 0x10, .bit = 0x00 - }, + }, /* BUC6 */ }; /* TMP0 - TMP5 are the same, all from GPADC */
Signature · 1 line
2.14.1
PATCH 117/190 drm/amdgpu: fix gpu reset crash
In reply to Sasha LevinFrom: Chunming Zhou <[email protected]>
[ Upstream commit 51687759be93fbc553f2727e86be25c38126ba93 ]
[ 413.687439] BUG: unable to handle kernel NULL pointer dereference at 0000000000000548 [ 413.687479] IP: [<ffffffff8109b175>] to_live_kthread+0x5/0x60 [ 413.687507] PGD 1efd12067 [ 413.687519] PUD 1efd11067 [ 413.687531] PMD 0
[ 413.687543] Oops: 0000 [#1] SMP [ 413.687557] Modules linked in: amdgpu(OE) ttm(OE) drm_kms_helper(E) drm(E) i2c_algo_bit(E) fb_sys_fops(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) rpcsec_gss_krb5(E) nfsv4(E) nfs(E) fscache(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) eeepc_wmi(E) snd_hda_codec(E) asus_wmi(E) snd_hda_core(E) sparse_keymap(E) snd_hwdep(E) video(E) snd_pcm(E) snd_seq_midi(E) joydev(E) snd_seq_midi_event(E) snd_rawmidi(E) snd_seq(E) snd_seq_device(E) snd_timer(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) snd(E) crc32_pclmul(E) ghash_clmulni_intel(E) soundcore(E) aesni_intel(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) shpchp(E) serio_raw(E) i2c_piix4(E) 8250_dw(E) i2c_designware_platform(E) i2c_designware_core(E) mac_hid(E) binfmt_misc(E) [ 413.687894] parport_pc(E) ppdev(E) lp(E) parport(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) autofs4(E) hid_generic(E) usbhid(E) hid(E) psmouse(E) ahci(E) r8169(E) mii(E) libahci(E) wmi(E) [ 413.687989] CPU: 13 PID: 1134 Comm: kworker/13:2 Tainted: G OE 4.9.0-custom #4 [ 413.688019] Hardware name: System manufacturer System Product Name/PRIME B350-PLUS, BIOS 0606 04/06/2017 [ 413.688089] Workqueue: events amd_sched_job_timedout [amdgpu] [ 413.688116] task: ffff88020f9657c0 task.stack: ffffc90001a88000 [ 413.688139] RIP: 0010:[<ffffffff8109b175>] [<ffffffff8109b175>] to_live_kthread+0x5/0x60 [ 413.688171] RSP: 0018:ffffc90001a8bd60 EFLAGS: 00010282 [ 413.688191] RAX: ffff88020f0073f8 RBX: ffff88020f000000 RCX: 0000000000000000 [ 413.688217] RDX: 0000000000000001 RSI: ffff88020f9670c0 RDI: 0000000000000000 [ 413.688243] RBP: ffffc90001a8bd78 R08: 0000000000000000 R09: 0000000000001000 [ 413.688269] R10: 0000006051b11a82 R11: 0000000000000001 R12: 0000000000000000 [ 413.688295] R13: ffff88020f002770 R14: ffff88020f004838 R15: ffff8801b23c2c60 [ 413.688321] FS: 0000000000000000(0000) GS:ffff88021ef40000(0000) knlGS:0000000000000000 [ 413.688352] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 413.688373] CR2: 0000000000000548 CR3: 00000001efd0f000 CR4: 00000000003406e0 [ 413.688399] Stack: [ 413.688407] ffffffff8109b304 ffff88020f000000 0000000000000070 ffffc90001a8bdf0 [ 413.688439] ffffffffa05ce29d ffffffffa052feb7 ffffffffa07b5820 ffffc90001a8bda0 [ 413.688470] ffffffff00000018 ffff8801bb88f060 0000000001a8bdb8 ffff88021ef59280 [ 413.688502] Call Trace: [ 413.688514] [<ffffffff8109b304>] ? kthread_park+0x14/0x60 [ 413.688555] [<ffffffffa05ce29d>] amdgpu_gpu_reset+0x7d/0x670 [amdgpu] [ 413.688589] [<ffffffffa052feb7>] ? drm_printk+0x97/0xa0 [drm] [ 413.688643] [<ffffffffa0698136>] amdgpu_job_timedout+0x46/0x50 [amdgpu] [ 413.688700] [<ffffffffa06969e7>] amd_sched_job_timedout+0x17/0x20 [amdgpu] [ 413.688727] [<ffffffff81095493>] process_one_work+0x153/0x3f0 [ 413.688751] [<ffffffff81095c5b>] worker_thread+0x12b/0x4b0 [ 413.688773] [<ffffffff8100392e>] ? do_syscall_64+0x6e/0x180 [ 413.688795] [<ffffffff81095b30>] ? rescuer_thread+0x350/0x350 [ 413.688818] [<ffffffff8100392e>] ? do_syscall_64+0x6e/0x180 [ 413.688839] [<ffffffff8109b423>] kthread+0xd3/0xf0 [ 413.688858] [<ffffffff8109b350>] ? kthread_park+0x60/0x60 [ 413.688881] [<ffffffff817e1ee5>] ret_from_fork+0x25/0x30 [ 413.688901] Code: 25 40 d3 00 00 48 8b 80 48 05 00 00 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <48> 8b b7 48 05 00 00 55 48 89 e5 48 85 f6 74 31 8b 97 f8 18 00 [ 413.689045] RIP [<ffffffff8109b175>] to_live_kthread+0x5/0x60 [ 413.689064] RSP <ffffc90001a8bd60> [ 413.689076] CR2: 0000000000000548 [ 413.697985] ---[ end trace 0a314a64821f84e9 ]---
The root cause is some ring doesn't have scheduler, like KIQ ring
--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +4 -3
@@ -2237,7 +2237,7 @@ int amdgpu_gpu_reset(struct amdgpu_device *adev)for (i =0 ; i <AMDGPU_MAX_RINGS ; ++i) {struct amdgpu_ring *ring = adev->rings[i]; -if (!ring) +if (!ring || !ring->sched.thread)continue ;kthread_park (ring->sched.thread);amd_sched_hw_job_reset (&ring->sched);
@@ -2326,7 +2326,8 @@ int amdgpu_gpu_reset(struct amdgpu_device *adev) }for (i =0 ; i <AMDGPU_MAX_RINGS ; ++i) {struct amdgpu_ring *ring = adev->rings[i]; -if (!ring) + +if (!ring || !ring->sched.thread)continue ;amd_sched_job_recovery (&ring->sched);
@@ -2335,7 +2336,7 @@ int amdgpu_gpu_reset(struct amdgpu_device *adev) }else {dev_err (adev->dev,"asic resume failed (%d).\n" , r);for (i =0 ; i <AMDGPU_MAX_RINGS ; ++i) { -if (adev->rings[i]) { +if (adev->rings[i] && adev->rings[i]->sched.thread) {kthread_unpark (adev->rings[i]->sched.thread); } }
Signature · 1 line
2.14.1
PATCH 118/190 drm/nouveau/kms: Increase max retries in scanout position queries.
In reply to Sasha LevinFrom: Mario Kleiner <[email protected]>
[ Upstream commit 60b95d709525e3ce1c51e1fc93175dcd1755d345 ]
So far we only allowed for 1 retry and just failed the query
- and thereby high precision vblank timestamping - if we did not get a reasonable result, as such a failure wasn't considered all too horrible. There are a few NVidia gpu models out there which may need a bit more than 1 retry to get a successful query result under some conditions.
Since Linux 4.4 the update code for vblank counter and timestamp in drm_update_vblank_count() changed so that the implementation assumes that high precision vblank timestamping of a kms driver either consistently succeeds or consistently fails for a given video mode and encoder/connector combo. Iow. switching from success to fail or vice versa on a modeset or connector change is ok, but spurious temporary failure for a given setup can confuse the core code and potentially cause bad miscounting of vblanks and confusion or hangs in userspace clients which rely on vblank stuff, e.g., desktop compositors.
Therefore change the max retry count to a larger number - more than any gpu so far is known to need to succeed, but still low enough so that these queries which do also happen in vblank interrupt are still fast enough to be not disastrously long if something would go badly wrong with them.
As such sporadic retries only happen seldom even on affected gpu's, this could mean a vblank irq could take a few dozen microseconds longer every few hours of uptime -- better than a desktop compositor randomly hanging every couple of hours or days of uptime in a hard to reproduce manner.
--- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/nouveau/nouveau_display.c +1 -1
@@ -106,7 +106,7 @@ nouveau_display_scanoutpos_head(struct drm_crtc *crtc, int *vpos, int *hpos, };struct nouveau_display *disp =nouveau_display (crtc->dev);struct drm_vblank_crtc *vblank = &crtc->dev->vblank[drm_crtc_index (crtc)]; -int ret, retry =1 ; +int ret, retry =20 ; do { ret = nvif_mthd(&disp->disp, 0, &args, sizeof(args));
Signature · 1 line
2.14.1
PATCH 119/190 jbd2: Fix lockdep splat with generic/270 test
In reply to Sasha LevinFrom: Jan Kara <[email protected]>
[ Upstream commit c52c47e4b4fbe4284602fc2ccbfc4a4d8dc05b49 ]
I've hit a lockdep splat with generic/270 test complaining that:
3216.fsstress.b/3533 is trying to acquire lock:
(jbd2_handle){++++..}, at: [<ffffffff813152e0>] jbd2_log_wait_commit+0x0/0x150
but task is already holding lock:
(jbd2_handle){++++..}, at: [<ffffffff8130bd3b>] start_this_handle+0x35b/0x850
The underlying problem is that jbd2_journal_force_commit_nested() (called from ext4_should_retry_alloc()) may get called while a transaction handle is started. In such case it takes care to not wait for commit of the running transaction (which would deadlock) but only for a commit of a transaction that is already committing (which is safe as that doesn't wait for any filesystem locks).
In fact there are also other callers of jbd2_log_wait_commit() that take care to pass tid of a transaction that is already committing and for those cases, the lockdep instrumentation is too restrictive and leading to false positive reports. Fix the problem by calling jbd2_might_wait_for_commit() from jbd2_log_wait_commit() only if the transaction isn't already committing.
--- fs/jbd2/journal.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
fs/jbd2/journal.c +14 -1
@@ -691,8 +691,21 @@ int jbd2_log_wait_commit(journal_t *journal, tid_t tid) {int err =0 ; -jbd2_might_wait_for_commit (journal);read_lock (&journal->j_state_lock); +#ifdef CONFIG_PROVE_LOCKING +/* +* Some callers make sure transaction is already committing and in that +* case we cannot block on open handles anymore. So don't warn in that +* case. +*/ +if (tid_gt (tid, journal->j_commit_sequence) && + (!journal->j_committing_transaction || + journal->j_committing_transaction->t_tid != tid)) { +read_unlock (&journal->j_state_lock); +jbd2_might_wait_for_commit (journal); +read_lock (&journal->j_state_lock); + } +#endif #ifdef CONFIG_JBD2_DEBUG if (!tid_geq (journal->j_commit_request, tid)) { printk(KERN_ERR
Signature · 1 line
2.14.1
PATCH 120/190 ixgbevf: fix size of queue stats length
In reply to Sasha LevinFrom: Emil Tantilov <[email protected]>
[ Upstream commit f87fc44770f54ff1b54d44ae9cec11f10efeca02 ]
IXGBEVF_QUEUE_STATS_LEN is based on ixgebvf_stats, not ixgbe_stats.
This change fixes a bug where ethtool -S displayed some empty fields.
--- drivers/net/ethernet/intel/ixgbevf/ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/ixgbevf/ethtool.c +1 -1
@@ -80,7 +80,7 @@ static struct ixgbe_stats ixgbevf_gstrings_stats[] = {#define IXGBEVF_QUEUE_STATS_LEN ( \ (((struct ixgbevf_adapter *)netdev_priv(netdev))->num_tx_queues + \ ((struct ixgbevf_adapter *)netdev_priv(netdev))->num_rx_queues) * \ - (sizeof(struct ixgbe_stats) / sizeof(u64))) + (sizeof(struct ixgbevf_stats) / sizeof(u64)))#define IXGBEVF_GLOBAL_STATS_LEN ARRAY_SIZE(ixgbevf_gstrings_stats)#define IXGBEVF_STATS_LEN (IXGBEVF_GLOBAL_STATS_LEN + IXGBEVF_QUEUE_STATS_LEN)
Signature · 1 line
2.14.1
PATCH 121/190 net: ethernet: ucc_geth: fix MEM_PART_MURAM mode
In reply to Sasha LevinFrom: Christophe Leroy <[email protected]>
[ Upstream commit 8b8642af15ed14b9a7a34d3401afbcc274533e13 ]
Since commit 5093bb965a163 ("powerpc/QE: switch to the cpm_muram implementation"), muram area is not part of immrbar mapping anymore so immrbar_virt_to_phys() is not usable anymore.
--- drivers/net/ethernet/freescale/ucc_geth.c | 8 +++----- include/soc/fsl/qe/qe.h | 1 + 2 files changed, 4 insertions(+), 5 deletions(-)
drivers/net/ethernet/freescale/ucc_geth.c +3 -5
@@ -2594,11 +2594,10 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth) }else if (ugeth->ug_info->uf_info.bd_mem_part ==MEM_PART_MURAM ) {out_be32 (&ugeth->p_send_q_mem_reg->sqqd[i].bd_ring_base, - (u32 )immrbar_virt_to_phys (ugeth-> - p_tx_bd_ring[i])); + (u32 )qe_muram_dma (ugeth->p_tx_bd_ring[i]));out_be32 (&ugeth->p_send_q_mem_reg->sqqd[i]. last_bd_completed_address, - (u32 )immrbar_virt_to_phys (endOfRing)); + (u32 )qe_muram_dma (endOfRing)); } }
@@ -2844,8 +2843,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth) }else if (ugeth->ug_info->uf_info.bd_mem_part ==MEM_PART_MURAM ) {out_be32 (&ugeth->p_rx_bd_qs_tbl[i].externalbdbaseptr, - (u32 )immrbar_virt_to_phys (ugeth-> - p_rx_bd_ring[i])); + (u32 )qe_muram_dma (ugeth->p_rx_bd_ring[i])); }/* rest of fields handled by QE */ }
include/soc/fsl/qe/qe.h +1 -0
@@ -243,6 +243,7 @@ static inline int qe_alive_during_sleep(void)#define qe_muram_free cpm_muram_free#define qe_muram_addr cpm_muram_addr#define qe_muram_offset cpm_muram_offset +#define qe_muram_dma cpm_muram_dma#define qe_setbits32 (_addr, _v) iowrite32be(ioread32be(_addr) | (_v), (_addr))#define qe_clrbits32 (_addr, _v) iowrite32be(ioread32be(_addr) & ~(_v), (_addr))
Signature · 1 line
2.14.1
PATCH 122/190 soc/fsl/qe: round brg_freq to 1kHz granularity
In reply to Sasha LevinFrom: Valentin Longchamp <[email protected]>
[ Upstream commit 2ccf80b7566cc035d903dd0ac5d7ebd25c2c1060 ]
Because of integer computation rounding in u-boot (that sets the QE brg-frequency DTS prop), the clk value is 99999999 Hz even though it is 100 MHz.
When setting brg clks that are exact divisors of 100 MHz, this small differnce plays a role and can result in lower clks to be output (for instance 20 MHz - divide by 5 - results in 16.666 MHz - divide by 6).
This patch fixes that by "forcing" the brg_clk to the nearest kHz when the difference is below 2 integer rounding errors (i.e. 4).
--- drivers/soc/fsl/qe/qe.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
drivers/soc/fsl/qe/qe.c +13 -0
@@ -163,11 +163,15 @@ EXPORT_SYMBOL(qe_issue_cmd);*/ static unsigned int brg_clk =0 ; +#define CLK_GRAN (1000) +#define CLK_GRAN_LIMIT (5) +unsigned int qe_get_brg_clk (void ) {struct device_node *qe;int size;const u32 *prop; +unsigned int mod;if (brg_clk)return brg_clk;
@@ -185,6 +189,15 @@ unsigned int qe_get_brg_clk(void)of_node_put (qe); +/* round this if near to a multiple of CLK_GRAN */ + mod = brg_clk %CLK_GRAN ; +if (mod) { +if (mod <CLK_GRAN_LIMIT ) + brg_clk -= mod; +else if (mod > (CLK_GRAN -CLK_GRAN_LIMIT )) + brg_clk +=CLK_GRAN - mod; + } +return brg_clk; }EXPORT_SYMBOL (qe_get_brg_clk);
Signature · 1 line
2.14.1
PATCH 123/190 Bluetooth: hci_ldisc: Add protocol check to hci_uart_dequeue()
In reply to Sasha LevinFrom: Dean Jenkins <[email protected]>
[ Upstream commit 048e1bd3a27fbeb84ccdff52e165370c1339a193 ]
Before attempting to dequeue a Data Link protocol encapsulated message, check that the Data Link protocol is still bound to the HCI UART driver. This makes the code consistent with the usage of the other proto function pointers.
Therefore, add a check for HCI_UART_PROTO_READY into hci_uart_dequeue() and return NULL if the Data Link protocol is not bound.
This is needed for robustness as there is a scheduling race condition. hci_uart_write_work() is scheduled to run via work queue hu->write_work from hci_uart_tx_wakeup(). Therefore, there is a delay between scheduling hci_uart_write_work() to run and hci_uart_dequeue() running whereby the Data Link protocol layer could become unbound during the scheduling delay. In this case, without the check, the call to the unbound Data Link protocol layer dequeue function can crash.
It is noted that hci_uart_tty_close() has a "cancel_work_sync(&hu->write_work)" statement but this only reduces the window of the race condition because it is possible for a new work-item to be added to work queue hu->write_work after the call to cancel_work_sync(). For example, Data Link layer retransmissions can be added to the work queue after the cancel_work_sync() has finished.
--- drivers/bluetooth/hci_ldisc.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/bluetooth/hci_ldisc.c +5 -3
@@ -113,10 +113,12 @@ static inline struct sk_buff *hci_uart_dequeue(struct hci_uart *hu) {struct sk_buff *skb = hu->tx_skb; -if (!skb) - skb = hu->proto->dequeue (hu); -else +if (!skb) { +if (test_bit (HCI_UART_PROTO_READY , &hu->flags)) + skb = hu->proto->dequeue (hu); + }else { hu->tx_skb =NULL ; + }return skb; }
Signature · 1 line
2.14.1
PATCH 124/190 Bluetooth: hci_ldisc: Add protocol check to hci_uart_tx_wakeup()
In reply to Sasha LevinFrom: Dean Jenkins <[email protected]>
[ Upstream commit 2d6f1da168e1d62c47f7d50135ac4cbd8411dcb1 ]
Before attempting to schedule a work-item onto hu->write_work in hci_uart_tx_wakeup(), check that the Data Link protocol layer is still bound to the HCI UART driver.
Failure to perform this protocol check causes a race condition between the work queue hu->write_work running hci_uart_write_work() and the Data Link protocol layer being unbound (closed) in hci_uart_tty_close().
Note hci_uart_tty_close() does have a "cancel_work_sync(&hu->write_work)" but it is ineffective because it cannot prevent work-items being added to hu->write_work after cancel_work_sync() has run.
Therefore, add a check for HCI_UART_PROTO_READY into hci_uart_tx_wakeup() which prevents scheduling of the work queue when HCI_UART_PROTO_READY is in the clear state. However, note a small race condition remains because the hci_uart_tx_wakeup() thread can run in parallel with the hci_uart_tty_close() thread so it is possible that a schedule of hu->write_work can occur when HCI_UART_PROTO_READY is cleared. A complete solution needs locking of the threads which is implemented in a future commit.
--- drivers/bluetooth/hci_ldisc.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/bluetooth/hci_ldisc.c +3 -0
@@ -125,6 +125,9 @@ static inline struct sk_buff *hci_uart_dequeue(struct hci_uart *hu)int hci_uart_tx_wakeup (struct hci_uart *hu) { +if (!test_bit (HCI_UART_PROTO_READY , &hu->flags)) +return 0 ; +if (test_and_set_bit (HCI_UART_SENDING , &hu->tx_state)) {set_bit (HCI_UART_TX_WAKEUP , &hu->tx_state);return 0 ;
Signature · 1 line
2.14.1
PATCH 125/190 vxlan: correctly handle ipv6.disable module parameter
In reply to Sasha LevinFrom: Jiri Benc <[email protected]>
[ Upstream commit d074bf9600443403aa24fbc12c1f18eadc90f5aa ]
When IPv6 is compiled but disabled at runtime, __vxlan_sock_add returns -EAFNOSUPPORT. For metadata based tunnels, this causes failure of the whole operation of bringing up the tunnel.
Ignore failure of IPv6 socket creation for metadata based tunnels caused by IPv6 not being available.
--- drivers/net/vxlan.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/net/vxlan.c +7 -3
@@ -2816,17 +2816,21 @@ static int __vxlan_sock_add(struct vxlan_dev *vxlan, bool ipv6)static int vxlan_sock_add (struct vxlan_dev *vxlan) { -bool ipv6 = vxlan->flags &VXLAN_F_IPV6 ;bool metadata = vxlan->flags &VXLAN_F_COLLECT_METADATA ; +bool ipv6 = vxlan->flags &VXLAN_F_IPV6 || metadata; +bool ipv4 = !ipv6 || metadata;int ret =0 ;RCU_INIT_POINTER (vxlan->vn4_sock,NULL );#if IS_ENABLED (CONFIG_IPV6 )RCU_INIT_POINTER (vxlan->vn6_sock,NULL ); -if (ipv6 || metadata) +if (ipv6) { ret =__vxlan_sock_add (vxlan, true); +if (ret <0 && ret != -EAFNOSUPPORT ) + ipv4 = false; + }#endif -if (!ret && (!ipv6 || metadata)) +if (ipv4) ret =__vxlan_sock_add (vxlan, false);if (ret <0 )vxlan_sock_release (vxlan);
Signature · 1 line
2.14.1
PATCH 126/190 qed: Unlock on error in qed_vf_pf_acquire()
In reply to Sasha LevinFrom: Dan Carpenter <[email protected]>
[ Upstream commit 66117a9d9a8ca948680d6554769ef9e88f936954 ]
My static checker complains that we're holding a mutex on this error path. Let's goto exit instead of returning directly.
--- drivers/net/ethernet/qlogic/qed/qed_vf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/qlogic/qed/qed_vf.c +1 -1
@@ -204,7 +204,7 @@ static int qed_vf_pf_acquire(struct qed_hwfn *p_hwfn)/* send acquire request */ rc =qed_send_msg2pf (p_hwfn, &resp->hdr.status,sizeof (*resp));if (rc) -return rc; + goto exit;/* copy acquire response from buffer to p_hwfn */ memcpy (&p_iov->acquire_resp, resp,sizeof (p_iov->acquire_resp));
Signature · 1 line
2.14.1
PATCH 127/190 bnx2x: Align RX buffers
In reply to Sasha LevinFrom: Scott Wood <[email protected]>
[ Upstream commit 9b70de6d0266888b3743f03802502e43131043c8 ]
The bnx2x driver is not providing proper alignment on the receive buffers it passes to build_skb(), causing skb_shared_info to be misaligned. skb_shared_info contains an atomic, and while PPC normally supports unaligned accesses, it does not support unaligned atomics.
Aligning the size of rx buffers will ensure that page_frag_alloc() returns aligned addresses.
This can be reproduced on PPC by setting the network MTU to 1450 (or other non-multiple-of-4) and then generating sufficient inbound network traffic (one or two large "wget"s usually does it), producing the following oops:
Unable to handle kernel paging request for unaligned access at address 0xc00000ffc43af656 Faulting instruction address: 0xc00000000080ef8c Oops: Kernel access of bad area, sig: 7 [#1] SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: vmx_crypto powernv_rng rng_core powernv_op_panel leds_powernv led_class nfsd ip_tables x_tables autofs4 xfs lpfc bnx2x mdio libcrc32c crc_t10dif crct10dif_generic crct10dif_common CPU: 104 PID: 0 Comm: swapper/104 Not tainted 4.11.0-rc8-00088-g4c761da #2
task: c00000ffd4892400 task.stack: c00000ffd4920000
NIP: c00000000080ef8c LR: c00000000080eee8 CTR: c0000000001f8320
REGS: c00000ffffc33710 TRAP: 0600 Not tainted (4.11.0-rc8-00088-g4c761da)
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
CR: 24082042 XER: 00000000
CFAR: c00000000080eea0 DAR: c00000ffc43af656 DSISR: 00000000 SOFTE: 1
GPR00: c000000000907f64 c00000ffffc33990 c000000000dd3b00 c00000ffcaf22100
GPR04: c00000ffcaf22e00 0000000000000000 0000000000000000 0000000000000000
GPR08: 0000000000b80008 c00000ffc43af636 c00000ffc43af656 0000000000000000
GPR12: c0000000001f6f00 c00000000fe1a000 000000000000049f 000000000000c51f
GPR16: 00000000ffffef33 0000000000000000 0000000000008a43 0000000000000001
GPR20: c00000ffc58a90c0 0000000000000000 000000000000dd86 0000000000000000
GPR24: c000007fd0ed10c0 00000000ffffffff 0000000000000158 000000000000014a
GPR28: c00000ffc43af010 c00000ffc9144000 c00000ffcaf22e00 c00000ffcaf22100 NIP [c00000000080ef8c] __skb_clone+0xdc/0x140
LR [c00000000080eee8] __skb_clone+0x38/0x140
Call Trace: [c00000ffffc33990] [c00000000080fb74] skb_clone+0x74/0x110 (unreliable) [c00000ffffc339c0] [c000000000907f64] packet_rcv+0x144/0x510 [c00000ffffc33a40] [c000000000827b64] __netif_receive_skb_core+0x5b4/0xd80 [c00000ffffc33b00] [c00000000082b2bc] netif_receive_skb_internal+0x2c/0xc0 [c00000ffffc33b40] [c00000000082c49c] napi_gro_receive+0x11c/0x260 [c00000ffffc33b80] [d000000066483d68] bnx2x_poll+0xcf8/0x17b0 [bnx2x] [c00000ffffc33d00] [c00000000082babc] net_rx_action+0x31c/0x480 [c00000ffffc33e10] [c0000000000d5a44] __do_softirq+0x164/0x3d0 [c00000ffffc33f00] [c0000000000d60a8] irq_exit+0x108/0x120 [c00000ffffc33f20] [c000000000015b98] __do_irq+0x98/0x200 [c00000ffffc33f90] [c000000000027f14] call_do_irq+0x14/0x24 [c00000ffd4923a90] [c000000000015d94] do_IRQ+0x94/0x110 [c00000ffd4923ae0] [c000000000008d90] hardware_interrupt_common+0x150/0x160
--- drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c +1 -0
@@ -2026,6 +2026,7 @@ static void bnx2x_set_rx_buf_size(struct bnx2x *bp)ETH_OVREHEAD + mtu +BNX2X_FW_RX_ALIGN_END ; + fp->rx_buf_size =SKB_DATA_ALIGN (fp->rx_buf_size);/* Note : rx_buf_size doesn't take into account NET_SKB_PAD */ if (fp->rx_buf_size +NET_SKB_PAD <=PAGE_SIZE ) fp->rx_frag_size = fp->rx_buf_size +NET_SKB_PAD ;
Signature · 1 line
2.14.1
PATCH 128/190 power: supply: bq24190_charger: Add disable-reset device-property
In reply to Sasha LevinFrom: Hans de Goede <[email protected]>
[ Upstream commit 6cf62a3b97e78ba41d31390e59a1ddc98a9e3622 ]
Allow platform-code to disable the reset on probe and suspend/resume by setting a "disable-reset" boolean device property on the device.
There are several reasons why the platform-code may want to disable the reset on probe and suspend/resume:
1) Resetting the charger should never be necessary it should always have sane values programmed. If it is running with invalid values while we are not running (system turned off or suspended) there is a big problem as that may lead to overcharging the battery.
2) The reset in suspend() is meant to put the charger back into default mode, but this is not necessary and not a good idea. If the charger has been programmed with a higher max charge_current / charge_voltage then putting it back in default-mode will reset those to the safe power-on defaults, leading to slower charging, or charging to a lower voltage (and thus not using the full capacity) while suspended which is undesirable. Reprogramming the max charge_current / charge_voltage after the reset will not help here as that will put the charger back in host mode and start the i2c watchdog if the host then does not do anything for 40s (iow if we're suspended for more then 40s) the watchdog expires resetting the device to default-mode, including resetting all the registers to there safe power-on defaults. So the only way to keep using custom charge settings while suspending is to keep the charger in its normal running state with the i2c watchdog disabled. This is fine as the charger will still automatically switch from constant current to constant voltage and stop charging when the battery is full.
3) Besides never being necessary resetting the charger also causes problems on systems where the charge voltage limit is set higher then the reset value, if this is the case and the charger is reset while charging and the battery voltage is between the 2 voltages, then about half the time the charger gets confused and claims to be charging (REG08 contains 0x64) but in reality the charger has decoupled itself from VBUS (Q1 off) and is drawing 0A from VBUS, leaving the system running from the battery.
This last problem is happening on a GPD-win mini PC with a bq24292i charger chip combined with a max17047 fuel-gauge and a LiHV battery. I've checked and TI does not list any errata for the bq24292i which could explain this (there are no errata at all).
--- drivers/power/supply/bq24190_charger.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/power/supply/bq24190_charger.c +3 -0
@@ -506,6 +506,9 @@ static int bq24190_register_reset(struct bq24190_dev_info *bdi)int ret, limit =100 ;u8 v; +if (device_property_read_bool (bdi->dev,"disable-reset" )) +return 0 ; +/* Reset the registers */ ret = bq24190_write_mask(bdi, BQ24190_REG_POC, BQ24190_REG_POC_RESET_MASK,
Signature · 1 line
2.14.1
PATCH 129/190 power: supply: isp1704: Fix unchecked return value of devm_kzalloc
In reply to Sasha LevinFrom: Pan Bian <[email protected]>
[ Upstream commit 8b20839988f1ed5e534b270f3776709b640dc7e0 ]
Function devm_kzalloc() will return a NULL pointer. However, in function isp1704_charger_probe(), the return value of devm_kzalloc() is directly used without validation. This may result in a bad memory access bug.
--- drivers/power/supply/isp1704_charger.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/power/supply/isp1704_charger.c +4 -0
@@ -418,6 +418,10 @@ static int isp1704_charger_probe(struct platform_device *pdev) pdata =devm_kzalloc (&pdev->dev,sizeof (struct isp1704_charger_data ),GFP_KERNEL ); +if (!pdata) { + ret = -ENOMEM ; + goto fail0; + } pdata->enable_gpio = gpio;dev_info (&pdev->dev,"init gpio %d\n" , pdata->enable_gpio);
Signature · 1 line
2.14.1
PATCH 130/190 power: supply: pda_power: move from timer to delayed_work
In reply to Sasha LevinFrom: Michael Trimarchi <[email protected]>
[ Upstream commit 633e8799ddc09431be2744c4a1efdbda13af2b0b ]
This changed is needed to avoid locking problem during boot as shown:
<5>[ 8.824096] Registering SWP/SWPB emulation handler
<6>[ 8.977294] clock: disabling unused clocks to save power
<3>[ 9.108154] BUG: sleeping function called from invalid context at kernel_albert/kernel/mutex.c:269
<3>[ 9.122894] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
<4>[ 9.130249] 3 locks held by swapper/0/1:
<4>[ 9.134613] #0: (&__lockdep_no_validate__){......}, at: [<c0342430>] __driver_attach+0x58/0xa8
<4>[ 9.144500] #1: (&__lockdep_no_validate__){......}, at: [<c0342440>] __driver_attach+0x68/0xa8
<4>[ 9.154357] #2: (&polling_timer){......}, at: [<c0053770>] run_timer_softirq+0x108/0x3ec
<4>[ 9.163726] Backtrace:
<4>[ 9.166473] [<c001269c>] (dump_backtrace+0x0/0x114) from [<c067e5f0>] (dump_stack+0x20/0x24)
<4>[ 9.175811] r6:00203230 r5:0000010d r4:d782e000 r3:60000113
<4>[ 9.182250] [<c067e5d0>] (dump_stack+0x0/0x24) from [<c007441c>] (__might_sleep+0x10c/0x128)
<4>[ 9.191650] [<c0074310>] (__might_sleep+0x0/0x128) from [<c0688f60>] (mutex_lock_nested+0x34/0x36c)
<4>[ 9.201660] r5:c02d5350 r4:d79a0c64
<4>[ 9.205688] [<c0688f2c>] (mutex_lock_nested+0x0/0x36c) from [<c02d5350>] (regulator_set_current_limit+0x30/0x118)
<4>[ 9.217071] [<c02d5320>] (regulator_set_current_limit+0x0/0x118) from [<c0435ce0>] (update_charger+0x84/0xc4)
<4>[ 9.228027] r7:d782fb20 r6:00000101 r5:c1767e94 r4:00000000
<4>[ 9.234436] [<c0435c5c>] (update_charger+0x0/0xc4) from [<c0435d40>] (psy_changed+0x20/0x48)
<4>[ 9.243804] r5:d782e000 r4:c1767e94
<4>[ 9.247802] [<c0435d20>] (psy_changed+0x0/0x48) from [<c0435dec>] (polling_timer_func+0x84/0xb8)
<4>[ 9.257537] r4:c1767e94 r3:00000002
<4>[ 9.261566] [<c0435d68>] (polling_timer_func+0x0/0xb8) from [<c00537e4>] (run_timer_softirq+0x17c/0x3ec)
<4>[ 9.272033] r4:c1767eb0 r3:00000000
<4>[ 9.276062] [<c0053668>] (run_timer_softirq+0x0/0x3ec) from [<c004b000>] (__do_softirq+0xf0/0x298)
<4>[ 9.286010] [<c004af10>] (__do_softirq+0x0/0x298) from [<c004b650>] (irq_exit+0x98/0xa0)
<4>[ 9.295013] [<c004b5b8>] (irq_exit+0x0/0xa0) from [<c000edbc>] (handle_IRQ+0x60/0xc0)
<4>[ 9.303680] r4:c1194e98 r3:c00bc778
<4>[ 9.307708] [<c000ed5c>] (handle_IRQ+0x0/0xc0) from [<c0008504>] (gic_handle_irq+0x34/0x68)
<4>[ 9.316955] r8:000ac383 r7:d782fc3c r6:d782fc08 r5:c11936c4 r4:e0802100
<4>[ 9.324310] r3:c026ba48
<4>[ 9.327301] [<c00084d0>] (gic_handle_irq+0x0/0x68) from [<c068c2c0>] (__irq_svc+0x40/0x74)
<4>[ 9.336456] Exception stack(0xd782fc08 to 0xd782fc50)
<4>[ 9.342041] fc00: d6e30e6c ac383627 00000000 ac383417 ea19c000 ea200000
<4>[ 9.351104] fc20: beffffff 00000667 000ac383 d6e30670 d6e3066c d782fc94 d782fbe8 d782fc50
<4>[ 9.360168] fc40: c026ba48 c001d1f0 00000113 ffffffff--- drivers/power/supply/pda_power.c | 49 ++++++++++++++++++++++------------------ 1 file changed, 27 insertions(+), 22 deletions(-)
drivers/power/supply/pda_power.c +27 -22
@@ -30,9 +30,9 @@ static inline unsigned int get_irq_flags(struct resource *res)static struct device *dev;static struct pda_power_pdata *pdata;static struct resource *ac_irq, *usb_irq; -static struct timer_list charger_timer; -static struct timer_list supply_timer; -static struct timer_list polling_timer; +static struct delayed_work charger_work; +static struct delayed_work polling_work; +static struct delayed_work supply_work;static int polling;static struct power_supply *pda_psy_ac, *pda_psy_usb;
@@ -140,7 +140,7 @@ static void update_charger(void) } } -static void supply_timer_func (unsigned long unused) +static void supply_work_func (struct work_struct *work) {if (ac_status ==PDA_PSY_TO_CHANGE ) { ac_status = new_ac_status;
@@ -161,11 +161,12 @@ static void psy_changed(void)* Okay, charger set. Now wait a bit before notifying supplicants, * charge power should stabilize. */ -mod_timer (&supply_timer, - jiffies +msecs_to_jiffies (pdata->wait_for_charger)); +cancel_delayed_work (&supply_work); +schedule_delayed_work (&supply_work, +msecs_to_jiffies (pdata->wait_for_charger)); } -static void charger_timer_func (unsigned long unused) +static void charger_work_func (struct work_struct *work) {update_status ();psy_changed ();
@@ -184,13 +185,14 @@ static irqreturn_t power_changed_isr(int irq, void *power_supply)* Wait a bit before reading ac/usb line status and setting charger, * because ac/usb status readings may lag from irq. */ -mod_timer (&charger_timer, - jiffies +msecs_to_jiffies (pdata->wait_for_status)); +cancel_delayed_work (&charger_work); +schedule_delayed_work (&charger_work, +msecs_to_jiffies (pdata->wait_for_status));return IRQ_HANDLED ; } -static void polling_timer_func (unsigned long unused) +static void polling_work_func (struct work_struct *work) {int changed =0 ;
@@ -211,8 +213,9 @@ static void polling_timer_func(unsigned long unused)if (changed)psy_changed (); -mod_timer (&polling_timer, - jiffies +msecs_to_jiffies (pdata->polling_interval)); +cancel_delayed_work (&polling_work); +schedule_delayed_work (&polling_work, +msecs_to_jiffies (pdata->polling_interval)); }#if IS_ENABLED (CONFIG_USB_PHY )
@@ -250,8 +253,9 @@ static int otg_handle_notification(struct notifier_block *nb,* Wait a bit before reading ac/usb line status and setting charger, * because ac/usb status readings may lag from irq. */ -mod_timer (&charger_timer, - jiffies +msecs_to_jiffies (pdata->wait_for_status)); +cancel_delayed_work (&charger_work); +schedule_delayed_work (&charger_work, +msecs_to_jiffies (pdata->wait_for_status));return NOTIFY_OK ; }
@@ -300,8 +304,8 @@ static int pda_power_probe(struct platform_device *pdev)if (!pdata->ac_max_uA) pdata->ac_max_uA =500000 ; -setup_timer (&charger_timer, charger_timer_func,0 ); -setup_timer (&supply_timer, supply_timer_func,0 ); +INIT_DELAYED_WORK (&charger_work, charger_work_func); +INIT_DELAYED_WORK (&supply_work, supply_work_func); ac_irq =platform_get_resource_byname (pdev,IORESOURCE_IRQ ,"ac" ); usb_irq =platform_get_resource_byname (pdev,IORESOURCE_IRQ ,"usb" );
@@ -385,9 +389,10 @@ static int pda_power_probe(struct platform_device *pdev)if (polling) {dev_dbg (dev,"will poll for status\n" ); -setup_timer (&polling_timer, polling_timer_func,0 ); -mod_timer (&polling_timer, - jiffies +msecs_to_jiffies (pdata->polling_interval)); +INIT_DELAYED_WORK (&polling_work, polling_work_func); +cancel_delayed_work (&polling_work); +schedule_delayed_work (&polling_work, +msecs_to_jiffies (pdata->polling_interval)); }if (ac_irq || usb_irq)
@@ -433,9 +438,9 @@ static int pda_power_remove(struct platform_device *pdev)free_irq (ac_irq->start, pda_psy_ac);if (polling) -del_timer_sync (&polling_timer); -del_timer_sync (&charger_timer); -del_timer_sync (&supply_timer); +cancel_delayed_work_sync (&polling_work); +cancel_delayed_work_sync (&charger_work); +cancel_delayed_work_sync (&supply_work);if (pdata->is_usb_online)power_supply_unregister (pda_psy_usb);
Signature · 1 line
2.14.1
PATCH 131/190 Input: twl4030-pwrbutton - use correct device for irq request
In reply to Sasha LevinFrom: Sebastian Reichel <[email protected]>
[ Upstream commit 3071e9dd6cd3f2290d770117330f2c8b2e9a97e4 ]
The interrupt should be requested for the platform device and not for the input device.
--- drivers/input/misc/twl4030-pwrbutton.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/input/misc/twl4030-pwrbutton.c +1 -1
@@ -70,7 +70,7 @@ static int twl4030_pwrbutton_probe(struct platform_device *pdev) pwr->phys ="twl4030_pwrbutton/input0" ; pwr->dev.parent = &pdev->dev; - err =devm_request_threaded_irq (&pwr->dev, irq,NULL , powerbutton_irq, + err =devm_request_threaded_irq (&pdev->dev, irq,NULL , powerbutton_irq,IRQF_TRIGGER_FALLING |IRQF_TRIGGER_RISING |IRQF_ONESHOT ,"twl4030_pwrbutton" , pwr);
Signature · 1 line
2.14.1
PATCH 132/190 IB/rxe: Don't clamp residual length to mtu
In reply to Sasha LevinFrom: Johannes Thumshirn <[email protected]>
[ Upstream commit d52418502e288b5c7e9e2e6cf1de5f1d3d79d2e1 ]
When reading a RDMA WRITE FIRST packet we copy the DMA length from the RDMA header into the qp->resp.resid variable for later use. Later in check_rkey() we clamp it to the MTU if the packet is an RDMA WRITE packet and has a residual length bigger than the MTU. Later in write_data_in() we subtract the payload of the packet from the residual length. If the packet happens to have a payload of exactly the MTU size we end up with a residual length of 0 despite the packet not being the last in the conversation. When the next packet in the conversation arrives, we don't have any residual length left and thus set the QP into an error state.
This broke NVMe over Fabrics functionality over rdma_rxe.ko
The patch was verified using the following test.
# echo eth0 > /sys/module/rdma_rxe/parameters/add
# nvme connect -t rdma -a 192.168.155.101 -s 1023 -n nvmf-test
# mkfs.xfs -fK /dev/nvme0n1
meta-data=/dev/nvme0n1 isize=256 agcount=4, agsize=65536 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=0 finobt=0, sparse=0
data = bsize=4096 blocks=262144, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
# mount /dev/nvme0n1 /tmp/
[ 148.923263] XFS (nvme0n1): Mounting V4 Filesystem
[ 148.961196] XFS (nvme0n1): Ending clean mount
# dd if=/dev/urandom of=test.bin bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 0.437991 s, 306 MB/s
# sha256sum test.bin
cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a test.bin
# cp test.bin /tmp/
sha256sum /tmp/test.bin
cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a /tmp/test.bin--- drivers/infiniband/sw/rxe/rxe_resp.c | 2 -- 1 file changed, 2 deletions(-)
drivers/infiniband/sw/rxe/rxe_resp.c +0 -2
@@ -471,8 +471,6 @@ static enum resp_states check_rkey(struct rxe_qp *qp, state =RESPST_ERR_LENGTH ; goto err; } - - qp->resp.resid = mtu; }else {if (pktlen != resid) { state =RESPST_ERR_LENGTH ;
Signature · 1 line
2.14.1
PATCH 133/190 md/raid10: skip spare disk as 'first' disk
In reply to Sasha LevinFrom: Shaohua Li <[email protected]>
[ Upstream commit b506335e5d2b4ec687dde392a3bdbf7601778f1d ]
Commit 6f287ca(md/raid10: reset the 'first' at the end of loop) ignores a case in reshape, the first rdev could be a spare disk, which shouldn't be accounted as the first disk since it doesn't include the offset info.
Fix: 6f287ca(md/raid10: reset the 'first' at the end of loop)
--- drivers/md/raid10.c | 1 + 1 file changed, 1 insertion(+)
drivers/md/raid10.c +1 -0
@@ -4089,6 +4089,7 @@ static int raid10_start_reshape(struct mddev *mddev) diff =0 ;if (first || diff < min_offset_diff) min_offset_diff = diff; + first =0 ; } }
Signature · 1 line
2.14.1
PATCH 134/190 ACPI / power: Delay turning off unused power resources after suspend
In reply to Sasha LevinFrom: Hans de Goede <[email protected]>
[ Upstream commit 8ece1d83346bcc431090d59a2184276192189cdd ]
Commit 660b1113e0f3 (ACPI / PM: Fix consistency check for power resources during resume) introduced a check for ACPI power resources which have been turned on by the BIOS during suspend and turns these back off again.
This is causing problems on a Dell Venue Pro 11 7130 (i5-4300Y) it causes the following messages to show up in dmesg:
[ 131.014605] ACPI: Waking up from system sleep state S3
[ 131.150271] acpi LNXPOWER:07: Turning OFF
[ 131.150323] acpi LNXPOWER:06: Turning OFF
[ 131.150911] acpi LNXPOWER:00: Turning OFF
[ 131.169014] ACPI : EC: interrupt unblocked
[ 131.181811] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 133.535728] pci_raw_set_power_state: 76 callbacks suppressed
[ 133.535735] iwlwifi 0000:01:00.0: Refused to change power state,
currently in D3
[ 133.597672] PM: noirq resume of devices complete after 2428.891 msecsFollowed by a bunch of iwlwifi errors later on and the pcie device dropping from the bus (acpiphp thinks it has been unplugged).
Disabling the turning off of unused power resources fixes this. Instead of adding a quirk for this system, this commit fixes this by moving the disabling of unused power resources to later in the resume sequence when the iwlwifi card has been moved out of D3 so the ref_count for its power resource no longer is 0.
This new behavior seems to match the intend of the original commit which commit-msg says: "(... which means that no devices are going to need them any time soon) and we should turn them off".
This also avoids power resources which we need when bringing devices out of D3 from getting bounced off and then back on again.
--- drivers/acpi/power.c | 10 ++++++++++ drivers/acpi/sleep.c | 1 + drivers/acpi/sleep.h | 1 + 3 files changed, 12 insertions(+)
drivers/acpi/power.c +10 -0
@@ -864,6 +864,16 @@ void acpi_resume_power_resources(void)mutex_unlock (&resource->resource_lock); } + +mutex_unlock (&power_resource_list_lock); +} + +void acpi_turn_off_unused_power_resources (void ) +{ +struct acpi_power_resource *resource; + +mutex_lock (&power_resource_list_lock); +list_for_each_entry_reverse (resource, &acpi_power_resource_list, list_node) {int result, state;
drivers/acpi/sleep.c +1 -0
@@ -474,6 +474,7 @@ static void acpi_pm_start(u32 acpi_state)*/ static void acpi_pm_end (void ) { +acpi_turn_off_unused_power_resources ();acpi_scan_lock_release ();/* * This is necessary in case acpi_pm_finish() is not called during a
drivers/acpi/sleep.h +1 -0
@@ -6,6 +6,7 @@ extern struct list_head acpi_wakeup_device_list;extern struct mutex acpi_device_lock;extern void acpi_resume_power_resources (void ); +extern void acpi_turn_off_unused_power_resources (void );static inline acpi_status acpi_set_waking_vector (u32 wakeup_address) {
Signature · 1 line
2.14.1
PATCH 135/190 ia64: fix module loading for gcc-5.4
In reply to Sasha LevinFrom: Sergei Trofimovich <[email protected]>
[ Upstream commit a25fb8508c1b80dce742dbeaa4d75a1e9f2c5617 ]
Starting from gcc-5.4+ gcc generates MLX instructions in more cases to refer local symbols:
https://gcc.gnu.org/PR60465
That caused ia64 module loader to choke on such instructions:
fuse: invalid slot number 1 for IMM64
The Linux kernel used to handle only case where relocation pointed to slot=2 instruction in the bundle. That limitation was fixed in linux by commit 9c184a073bfd ("[IA64] Fix 2.6 kernel for the new ia64 assembler") See
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1433
This change lifts the slot=2 restriction from the kernel module loader.
Tested on 'fuse' and 'btrfs' kernel modules.
--- arch/ia64/kernel/module.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/ia64/kernel/module.c +2 -2
@@ -153,7 +153,7 @@ slot (const struct insn *insn)static int apply_imm64 (struct module *mod,struct insn *insn,uint64_t val) { -if (slot (insn) !=2 ) { +if (slot (insn) !=1 &&slot (insn) !=2 ) {printk (KERN_ERR "%s: invalid slot number %d for IMM64\n" , mod->name,slot (insn));return 0 ;
@@ -165,7 +165,7 @@ apply_imm64 (struct module *mod, struct insn *insn, uint64_t val)static int apply_imm60 (struct module *mod,struct insn *insn,uint64_t val) { -if (slot (insn) !=2 ) { +if (slot (insn) !=1 &&slot (insn) !=2 ) {printk (KERN_ERR "%s: invalid slot number %d for IMM60\n" , mod->name,slot (insn));return 0 ;
Signature · 1 line
2.14.1
PATCH 136/190 tcm_fileio: Prevent information leak for short reads
In reply to Sasha LevinFrom: Dmitry Monakhov <[email protected]>
[ Upstream commit f11b55d13563e9428c88c873f4f03a6bef11ec0a ]
If we failed to read data from backing file (probably because some one truncate file under us), we must zerofill cmd's data, otherwise it will be returned as is. Most likely cmd's data are unitialized pages from page cache. This result in information leak.
(Change BUG_ON into -EINVAL se_cmd failure - nab)
testcase: https://github.com/dmonakhov/xfstests/commit/e11a1b7b907ca67b1be51a1594025600767366d5
--- drivers/target/target_core_file.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-)
drivers/target/target_core_file.c +17 -6
@@ -276,12 +276,11 @@ static int fd_do_rw(struct se_cmd *cmd, struct file *fd,else ret =vfs_iter_read (fd, &iter, &pos); -kfree (bvec); -if (is_write) {if (ret <0 || ret != data_length) {pr_err ("%s() write returned %d\n" , __func__, ret); -return (ret <0 ? ret : -EINVAL ); +if (ret >=0 ) + ret = -EINVAL ; } }else {/*
@@ -294,17 +293,29 @@ static int fd_do_rw(struct se_cmd *cmd, struct file *fd,pr_err ("%s() returned %d, expecting %u for " "S_ISBLK\n" , __func__, ret, data_length); -return (ret <0 ? ret : -EINVAL ); +if (ret >=0 ) + ret = -EINVAL ; } }else {if (ret <0 ) {pr_err ("%s() returned %d for non S_ISBLK\n" , __func__, ret); -return ret; + }else if (ret != data_length) { +/* +* Short read case: +* Probably some one truncate file under us. +* We must explicitly zero sg-pages to prevent +* expose uninizialized pages to userspace. +*/ +if (ret < data_length) + ret +=iov_iter_zero (data_length - ret, &iter); +else + ret = -EINVAL ; } } } -return 1 ; +kfree (bvec); +return ret; } static sense_reason_t
Signature · 1 line
2.14.1
PATCH 137/190 x86/xen: split xen_smp_prepare_boot_cpu()
In reply to Sasha LevinFrom: Vitaly Kuznetsov <[email protected]>
[ Upstream commit a2d1078a35f9a38ae888aa6147e4ca32666154a1 ]
Split xen_smp_prepare_boot_cpu() into xen_pv_smp_prepare_boot_cpu() and xen_hvm_smp_prepare_boot_cpu() to support further splitting of smp.c.
--- arch/x86/xen/smp.c | 49 ++++++++++++++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 19 deletions(-)
arch/x86/xen/smp.c +30 -19
@@ -299,35 +299,46 @@ static void __init xen_filter_cpu_maps(void) } -static void __init xen_smp_prepare_boot_cpu (void ) +static void __init xen_pv_smp_prepare_boot_cpu (void ) {BUG_ON (smp_processor_id () !=0 );native_smp_prepare_boot_cpu (); -if (xen_pv_domain ()) { -if (!xen_feature (XENFEAT_writable_page_tables)) -/* We've switched to the "real" per-cpu gdt, so make -* sure the old memory can be recycled. */ -make_lowmem_page_readwrite (xen_initial_gdt); +if (!xen_feature (XENFEAT_writable_page_tables)) +/* We've switched to the "real" per-cpu gdt, so make +* sure the old memory can be recycled. */ +make_lowmem_page_readwrite (xen_initial_gdt);#ifdef CONFIG_X86_32 -/* -* Xen starts us with XEN_FLAT_RING1_DS, but linux code -* expects __USER_DS -*/ -loadsegment (ds, __USER_DS); -loadsegment (es, __USER_DS); +/* +* Xen starts us with XEN_FLAT_RING1_DS, but linux code +* expects __USER_DS +*/ +loadsegment (ds, __USER_DS); +loadsegment (es, __USER_DS);#endif -xen_filter_cpu_maps (); -xen_setup_vcpu_info_placement (); - } +xen_filter_cpu_maps (); +xen_setup_vcpu_info_placement (); + +/* +* The alternative logic (which patches the unlock/lock) runs before +* the smp bootup up code is activated. Hence we need to set this up +* the core kernel is being patched. Otherwise we will have only +* modules patched but not core code. +*/ +xen_init_spinlocks (); +} + +static void __init xen_hvm_smp_prepare_boot_cpu (void ) +{ +BUG_ON (smp_processor_id () !=0 ); +native_smp_prepare_boot_cpu ();/* * Setup vcpu_info for boot CPU. */ -if (xen_hvm_domain ()) -xen_vcpu_setup (0 ); +xen_vcpu_setup (0 );/* * The alternative logic (which patches the unlock/lock) runs before
@@ -733,7 +744,7 @@ static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id) }static const struct smp_ops xen_smp_ops__initconst = { - .smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu, + .smp_prepare_boot_cpu = xen_pv_smp_prepare_boot_cpu, .smp_prepare_cpus = xen_smp_prepare_cpus, .smp_cpus_done = xen_smp_cpus_done,
@@ -772,5 +783,5 @@ void __init xen_hvm_smp_init(void) smp_ops.cpu_die = xen_cpu_die; smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi; smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi; - smp_ops.smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu; + smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu; }
Signature · 1 line
2.14.1
PATCH 138/190 video: fbdev: udlfb: Fix buffer on stack
In reply to Sasha LevinFrom: Maksim Salau <[email protected]>
[ Upstream commit 45f580c42e5c125d55dbd8099750a1998de3d917 ]
Allocate buffers on HEAP instead of STACK for local array that is to be sent using usb_control_msg().
--- drivers/video/fbdev/udlfb.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
drivers/video/fbdev/udlfb.c +12 -2
@@ -1487,15 +1487,25 @@ static struct device_attribute fb_device_attrs[] = {static int dlfb_select_std_channel (struct dlfb_data *dev) {int ret; -u8 set_def_chn[] = {0x57 ,0xCD ,0xDC ,0xA7 , +void *buf; +static const u8 set_def_chn[] = { +0x57 ,0xCD ,0xDC ,0xA7 ,0x1C ,0x88 ,0x5E ,0x15 ,0x60 ,0xFE ,0xC6 ,0x97 ,0x16 ,0x3D ,0x47 ,0xF2 }; + buf =kmemdup (set_def_chn,sizeof (set_def_chn),GFP_KERNEL ); + +if (!buf) +return -ENOMEM ; + ret =usb_control_msg (dev->udev,usb_sndctrlpipe (dev->udev,0 ),NR_USB_REQUEST_CHANNEL , (USB_DIR_OUT |USB_TYPE_VENDOR ),0 ,0 , - set_def_chn,sizeof (set_def_chn),USB_CTRL_SET_TIMEOUT ); + buf,sizeof (set_def_chn),USB_CTRL_SET_TIMEOUT ); + +kfree (buf); +return ret; }
Signature · 1 line
2.14.1
PATCH 139/190 sm501fb: don't return zero on failure path in sm501fb_start()
In reply to Sasha LevinFrom: Alexey Khoroshilov <[email protected]>
[ Upstream commit dc85e9a87420613b3129d5cc5ecd79c58351c546 ]
If fbmem iomemory mapping failed, sm501fb_start() breaks off initialization, deallocates resources, but returns zero. As a result, double deallocation can happen in sm501fb_stop().
Found by Linux Driver Verification project (linuxtesting.org).
--- drivers/video/fbdev/sm501fb.c | 1 + 1 file changed, 1 insertion(+)
drivers/video/fbdev/sm501fb.c +1 -0
@@ -1600,6 +1600,7 @@ static int sm501fb_start(struct sm501fb_info *info, info->fbmem =ioremap (res->start,resource_size (res));if (info->fbmem ==NULL ) {dev_err (dev,"cannot remap framebuffer\n" ); + ret = -ENXIO ; goto err_mem_res; }
Signature · 1 line
2.14.1
PATCH 140/190 pNFS: Fix a deadlock when coalescing writes and returning the layout
In reply to Sasha LevinFrom: Trond Myklebust <[email protected]>
[ Upstream commit 61f454e30c18a28924e96be12592c0d5e24bcc81 ]
Consider the following deadlock:
Process P1 Process P2 Process P3
========== ========== ==========
lock_page(page)
lseg = pnfs_update_layout(inode)
lo = NFS_I(inode)->layoutpnfs_error_mark_layout_for_return(lo)
lock_page(page)
lseg = pnfs_update_layout(inode)
In this scenario,
- P1 has declared the layout to be in error, but P2 holds a reference to a layout segment on that inode, so the layoutreturn is deferred.
- P2 is waiting for a page lock held by P3.
- P3 is asking for a new layout segment, but is blocked waiting for the layoutreturn.
The fix is to ensure that pnfs_error_mark_layout_for_return() does not set the NFS_LAYOUT_RETURN flag, which blocks P3. Instead, we allow the latter to call LAYOUTGET so that it can make progress and unblock P2.
--- fs/nfs/pnfs.c | 2 -- 1 file changed, 2 deletions(-)
fs/nfs/pnfs.c +0 -2
@@ -1953,8 +1953,6 @@ void pnfs_error_mark_layout_for_return(struct inode *inode,spin_lock (&inode->i_lock);pnfs_set_plh_return_info (lo, range.iomode,0 ); -/* Block LAYOUTGET */ -set_bit (NFS_LAYOUT_RETURN , &lo->plh_flags);/* * mark all matching lsegs so that we are sure to have no live * segments at hand when sending layoutreturn. See pnfs_put_lseg()
Signature · 1 line
2.14.1
PATCH 141/190 net: hns: fix ethtool_get_strings overflow in hns driver
In reply to Sasha LevinFrom: Timmy Li <[email protected]>
[ Upstream commit 412b65d15a7f8a93794653968308fc100f2aa87c ]
hns_get_sset_count() returns HNS_NET_STATS_CNT and the data space allocated is not enough for ethtool_get_strings(), which will cause random memory corruption.
When SLAB and DEBUG_SLAB are both enabled, memory corruptions like the the following can be observed without this patch:
[ 43.115200] Slab corruption (Not tainted): Acpi-ParseExt start=ffff801fb0b69030, len=80 [ 43.115206] Redzone: 0x9f911029d006462/0x5f78745f31657070. [ 43.115208] Last user: [<5f7272655f746b70>](0x5f7272655f746b70) [ 43.115214] 010: 70 70 65 31 5f 74 78 5f 70 6b 74 00 6b 6b 6b 6b ppe1_tx_pkt.kkkk [ 43.115217] 030: 70 70 65 31 5f 74 78 5f 70 6b 74 5f 6f 6b 00 6b ppe1_tx_pkt_ok.k [ 43.115218] Next obj: start=ffff801fb0b69098, len=80 [ 43.115220] Redzone: 0x706d655f6f666966/0x9f911029d74e35b. [ 43.115229] Last user: [<ffff0000084b11b0>](acpi_os_release_object+0x28/0x38) [ 43.115231] 000: 74 79 00 6b 6b 6b 6b 6b 70 70 65 31 5f 74 78 5f ty.kkkkkppe1_tx_ [ 43.115232] 010: 70 6b 74 5f 65 72 72 5f 63 73 75 6d 5f 66 61 69 pkt_err_csum_fai
--- drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 2 +- drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 2 +- drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 2 +- drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c +1 -1
@@ -672,7 +672,7 @@ static void hns_gmac_get_strings(u32 stringset, u8 *data)static int hns_gmac_get_sset_count (int stringset) { -if (stringset ==ETH_SS_STATS ) +if (stringset ==ETH_SS_STATS || stringset ==ETH_SS_PRIV_FLAGS )return ARRAY_SIZE (g_gmac_stats_string);return 0 ;
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c +1 -1
@@ -422,7 +422,7 @@ void hns_ppe_update_stats(struct hns_ppe_cb *ppe_cb)int hns_ppe_get_sset_count (int stringset) { -if (stringset ==ETH_SS_STATS ) +if (stringset ==ETH_SS_STATS || stringset ==ETH_SS_PRIV_FLAGS )return ETH_PPE_STATIC_NUM ;return 0 ; }
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c +1 -1
@@ -799,7 +799,7 @@ void hns_rcb_get_stats(struct hnae_queue *queue, u64 *data)*/ int hns_rcb_get_ring_sset_count (int stringset) { -if (stringset ==ETH_SS_STATS ) +if (stringset ==ETH_SS_STATS || stringset ==ETH_SS_PRIV_FLAGS )return HNS_RING_STATIC_REG_NUM ;return 0 ;
drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c +1 -1
@@ -776,7 +776,7 @@ static void hns_xgmac_get_strings(u32 stringset, u8 *data)*/ static int hns_xgmac_get_sset_count (int stringset) { -if (stringset ==ETH_SS_STATS ) +if (stringset ==ETH_SS_STATS || stringset ==ETH_SS_PRIV_FLAGS )return ARRAY_SIZE (g_xgmac_stats_string);return 0 ;
Signature · 1 line
2.14.1
PATCH 142/190 cifs: small underflow in cnvrtDosUnixTm()
In reply to Sasha LevinFrom: Dan Carpenter <[email protected]>
[ Upstream commit 564277eceeca01e02b1ef3e141cfb939184601b4 ]
January is month 1. There is no zero-th month. If someone passes a zero month then it means we read from one space before the start of the total_days_of_prev_months[] array.
We may as well also be strict about days as well.
--- fs/cifs/netmisc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
fs/cifs/netmisc.c +3 -3
@@ -980,10 +980,10 @@ struct timespec cnvrtDosUnixTm(__le16 le_date, __le16 le_time, int offset)cifs_dbg (VFS ,"illegal hours %d\n" , st->Hours); days = sd->Day; month = sd->Month; -if ((days >31 ) || (month >12 )) { +if (days <1 || days >31 || month <1 || month >12 ) {cifs_dbg (VFS ,"illegal date, month %d day: %d\n" , month, days); -if (month >12 ) - month =12 ; + days =clamp (days,1 ,31 ); + month =clamp (month,1 ,12 ); } month -=1 ; days += total_days_of_prev_months[month];
Signature · 1 line
2.14.1
PATCH 143/190 mm: fix check for reclaimable pages in PF_MEMALLOC reclaim throttling
In reply to Sasha LevinFrom: Johannes Weiner <[email protected]>
[ Upstream commit d450abd81b081d45adb12f303a07dd44b15eb1bc ]
PF_MEMALLOC direct reclaimers get throttled on a node when the sum of all free pages in each zone fall below half the min watermark. During the summation, we want to exclude zones that don't have reclaimables. Checking the same pgdat over and over again doesn't make sense.
--- mm/vmscan.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
mm/vmscan.c +4 -2
@@ -2841,8 +2841,10 @@ static bool allow_direct_reclaim(pg_data_t *pgdat)for (i =0 ; i <=ZONE_NORMAL ; i++) { zone = &pgdat->node_zones[i]; -if (!managed_zone (zone) || -pgdat_reclaimable_pages (pgdat) ==0 ) +if (!managed_zone (zone)) +continue ; + +if (!zone_reclaimable_pages (zone))continue ; pfmemalloc_reserve +=min_wmark_pages (zone);
Signature · 1 line
2.14.1
PATCH 144/190 mm, vmstat: suppress pcp stats for unpopulated zones in zoneinfo
In reply to Sasha LevinFrom: David Rientjes <[email protected]>
[ Upstream commit 7dfb8bf3b9caef4049bee51d2c22e1c3a311d483 ]
After "mm, vmstat: print non-populated zones in zoneinfo", /proc/zoneinfo will show unpopulated zones.
The per-cpu pageset statistics are not relevant for unpopulated zones and can be potentially lengthy, so supress them when they are not interesting.
Also moves lowmem reserve protection information above pcp stats since it is relevant for all zones per vm.lowmem_reserve_ratio.
--- mm/vmstat.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-)
mm/vmstat.c +13 -7
@@ -1387,18 +1387,24 @@ static void zoneinfo_show_print(struct seq_file *m, pg_data_t *pgdat, zone->present_pages, zone->managed_pages); -for (i =0 ; i <NR_VM_ZONE_STAT_ITEMS ; i++) -seq_printf (m,"\n %-12s %lu" , vmstat_text[i], -zone_page_state (zone, i)); -seq_printf (m,"\n protection: (%ld" , zone->lowmem_reserve[0 ]);for (i =1 ; i <ARRAY_SIZE (zone->lowmem_reserve); i++)seq_printf (m,", %ld" , zone->lowmem_reserve[i]); -seq_printf (m, -")" -"\n pagesets" ); +seq_putc (m,')' ); + +/* If unpopulated, no other information is useful */ +if (!populated_zone (zone)) { +seq_putc (m,'\n' ); +return ; + } + +for (i =0 ; i <NR_VM_ZONE_STAT_ITEMS ; i++) +seq_printf (m,"\n %-12s %lu" , vmstat_text[i], +zone_page_state (zone, i)); + +seq_printf (m,"\n pagesets" );for_each_online_cpu (i) {struct per_cpu_pageset *pageset;
Signature · 1 line
2.14.1
PATCH 145/190 oom: improve oom disable handling
In reply to Sasha LevinFrom: Michal Hocko <[email protected]>
[ Upstream commit d75da004c708c9fca7b53f7da293a295522414d9 ]
Tetsuo has reported that sysrq triggered OOM killer will print a misleading information when no tasks are selected:
sysrq: SysRq : Manual OOM execution
Out of memory: Kill process 4468 ((agetty)) score 0 or sacrifice child
Killed process 4468 ((agetty)) total-vm:43704kB, anon-rss:1760kB, file-rss:0kB, shmem-rss:0kB
sysrq: SysRq : Manual OOM execution
Out of memory: Kill process 4469 (systemd-cgroups) score 0 or sacrifice child Killed process 4469 (systemd-cgroups) total-vm:10704kB, anon-rss:120kB, file-rss:0kB, shmem-rss:0kB
sysrq: SysRq : Manual OOM execution
sysrq: OOM request ignored because killer is disabled
sysrq: SysRq : Manual OOM execution
sysrq: OOM request ignored because killer is disabled
sysrq: SysRq : Manual OOM execution
sysrq: OOM request ignored because killer is disabled
The real reason is that there are no eligible tasks for the OOM killer to select but since commit 7c5f64f84483 ("mm: oom: deduplicate victim selection code for memcg and global oom") the semantic of out_of_memory has changed without updating moom_callback.
This patch updates moom_callback to tell that no task was eligible which is the case for both oom killer disabled and no eligible tasks. In order to help distinguish first case from the second add printk to both oom_killer_{enable,disable}. This information is useful on its own because it might help debugging potential memory allocation failures.
--- drivers/tty/sysrq.c | 2 +- mm/oom_kill.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-)
drivers/tty/sysrq.c +1 -1
@@ -375,7 +375,7 @@ static void moom_callback(struct work_struct *ignored)mutex_lock (&oom_lock);if (!out_of_memory (&oc)) -pr_info ("OOM request ignored because killer is disabled\n" ); +pr_info ("OOM request ignored. No task eligible\n" );mutex_unlock (&oom_lock); }
mm/oom_kill.c +2 -0
@@ -706,6 +706,7 @@ void exit_oom_victim(void)void oom_killer_enable (void ) { oom_killer_disabled = false; +pr_info ("OOM killer enabled.\n" ); }/**
@@ -742,6 +743,7 @@ bool oom_killer_disable(signed long timeout)oom_killer_enable ();return false; } +pr_info ("OOM killer disabled.\n" );return true; }
Signature · 1 line
2.14.1
PATCH 146/190 mm: hwpoison: call shake_page() after try_to_unmap() for mlocked page
In reply to Sasha LevinFrom: Naoya Horiguchi <[email protected]>
[ Upstream commit 286c469a988fbaf68e3a97ddf1e6c245c1446968 ]
Memory error handler calls try_to_unmap() for error pages in various states. If the error page is a mlocked page, error handling could fail with "still referenced by 1 users" message. This is because the page is linked to and stays in lru cache after the following call chain.
try_to_unmap_one
page_remove_rmap
clear_page_mlock
putback_lru_page
lru_cache_add
memory_failure() calls shake_page() to hanlde the similar issue, but current code doesn't cover because shake_page() is called only before try_to_unmap(). So this patches adds shake_page().
--- mm/memory-failure.c | 8 ++++++++ 1 file changed, 8 insertions(+)
mm/memory-failure.c +8 -0
@@ -921,6 +921,7 @@ static int hwpoison_user_mappings(struct page *p, unsigned long pfn,int ret;int kill =1 , forcekill;struct page *hpage = *hpagep; +bool mlocked =PageMlocked (hpage);/* * Here we are interested only in user-mapped pages, so skip any
@@ -984,6 +985,13 @@ static int hwpoison_user_mappings(struct page *p, unsigned long pfn,pr_err ("Memory failure: %#lx: failed to unmap page (mapcount=%d)\n" , pfn,page_mapcount (hpage)); +/* +* try_to_unmap() might put mlocked page in lru cache, so call +* shake_page() again to ensure that it's flushed. +*/ +if (mlocked) +shake_page (hpage,0 ); +/* * Now that the dirty bit has been propagated to the * struct page and all unmaps done we can decide if
Signature · 1 line
2.14.1
PATCH 147/190 rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks
In reply to Sasha LevinFrom: Moritz Fischer <[email protected]>
[ Upstream commit 453d0744f6c6ca3f9749b8c57c2e85b5b9f52514 ]
The issue is that the internal counter that triggers the watchdog reset is actually running at 4096 Hz instead of 1Hz, therefore the value given by userland (in sec) needs to be multiplied by 4096 to get the correct behavior.
--- drivers/rtc/rtc-ds1374.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/rtc/rtc-ds1374.c +6 -1
@@ -527,6 +527,10 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned int cmd,if (get_user (new_margin, (int __user *)arg))return -EFAULT ; +/* the hardware's tick rate is 4096 Hz, so +* the counter value needs to be scaled accordingly +*/ + new_margin <<=12 ;if (new_margin <1 || new_margin >16777216 )return -EINVAL ;
@@ -535,7 +539,8 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned int cmd,ds1374_wdt_ping ();/* fallthrough */ case WDIOC_GETTIMEOUT : -return put_user (wdt_margin, (int __user *)arg); +/* when returning ... inverse is true */ +return put_user ((wdt_margin >>12 ), (int __user *)arg);case WDIOC_SETOPTIONS :if (copy_from_user (&options, (int __user *)arg,sizeof (int )))return -EFAULT ;
Signature · 1 line
2.14.1
PATCH 148/190 rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL
In reply to Sasha LevinFrom: Moritz Fischer <[email protected]>
[ Upstream commit 538c08f4c89580fc644e2bc64e0a4b86c925da4e ]
The WDIOC_SETOPTIONS case in the watchdog ioctl would alwayss falls through to the -EINVAL case. This is wrong since thew watchdog does actually get stopped or started correctly.
--- drivers/rtc/rtc-ds1374.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/rtc/rtc-ds1374.c +2 -1
@@ -548,14 +548,15 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned int cmd,if (options &WDIOS_DISABLECARD ) {pr_info ("disable watchdog\n" );ds1374_wdt_disable (); +return 0 ; }if (options &WDIOS_ENABLECARD ) {pr_info ("enable watchdog\n" );ds1374_wdt_settimeout (wdt_margin);ds1374_wdt_ping (); +return 0 ; } -return -EINVAL ; }return -ENOTTY ;
Signature · 1 line
2.14.1
PATCH 149/190 ath10k: fix out of bounds access to local buffer
In reply to Sasha LevinFrom: Michael Mera <[email protected]>
[ Upstream commit a16703aaeaedec7a8bee5be5522c7c3e75478951 ]
During write to debugfs file simulate_fw_crash, fixed-size local buffer 'buf' is accessed and modified at index 'count-1', where 'count' is the size of the write (so potentially out of bounds).
This patch fixes this problem.
--- drivers/net/wireless/ath/ath10k/debug.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
drivers/net/wireless/ath/ath10k/debug.c +10 -6
@@ -624,17 +624,21 @@ static ssize_t ath10k_write_simulate_fw_crash(struct file *file, size_t count, loff_t *ppos) { struct ath10k *ar = file->private_data; -char buf[32 ]; +char buf[32 ] = {0 }; +ssize_t rc;int ret; -simple_write_to_buffer (buf,sizeof (buf) -1 , ppos, user_buf, count); +/* filter partial writes and invalid commands */ +if (*ppos !=0 || count >=sizeof (buf) || count ==0 ) +return -EINVAL ; -/* make sure that buf is null terminated */ - buf[sizeof (buf) -1 ] =0 ; + rc =simple_write_to_buffer (buf,sizeof (buf) -1 , ppos, user_buf, count); +if (rc <0 ) +return rc;/* drop the possible '\n' from the end */ -if (buf[count -1 ] =='\n' ) - buf[count -1 ] =0 ; +if (buf[*ppos -1 ] =='\n' ) + buf[*ppos -1 ] ='\0' ;mutex_lock (&ar->conf_mutex);
Signature · 1 line
2.14.1
PATCH 150/190 perf tests kmod-path: Don't fail if compressed modules aren't supported
In reply to Sasha LevinFrom: Kim Phillips <[email protected]>
[ Upstream commit 805b151a1afd24414706a7f6ae275fbb9649be74 ]
__kmod_path__parse() uses is_supported_compression() to determine and parse out compressed module file extensions. On systems without zlib, this test fails and __kmod_path__parse() continues to strcmp "ko" with "gz". Don't do this on those systems.
--- tools/perf/tests/kmod-path.c | 2 ++ 1 file changed, 2 insertions(+)
tools/perf/tests/kmod-path.c +2 -0
@@ -61,6 +61,7 @@ int test__kmod_path__parse(int subtest __maybe_unused)M ("/xxxx/xxxx/x-x.ko" ,PERF_RECORD_MISC_KERNEL , true);M ("/xxxx/xxxx/x-x.ko" ,PERF_RECORD_MISC_USER , false); +#ifdef HAVE_ZLIB_SUPPORT /* path alloc_name alloc_ext kmod comp name ext */ T ("/xxxx/xxxx/x.ko.gz" , true , true , true, true,"[x]" ,"gz" );T ("/xxxx/xxxx/x.ko.gz" , false , true , true, true,NULL ,"gz" );
@@ -96,6 +97,7 @@ int test__kmod_path__parse(int subtest __maybe_unused)M ("x.ko.gz" ,PERF_RECORD_MISC_CPUMODE_UNKNOWN , true);M ("x.ko.gz" ,PERF_RECORD_MISC_KERNEL , true);M ("x.ko.gz" ,PERF_RECORD_MISC_USER , false); +#endif /* path alloc_name alloc_ext kmod comp name ext */ T ("[test_module]" , true , true , true, false,"[test_module]" ,NULL );
Signature · 1 line
2.14.1
PATCH 151/190 block/mq: Cure cpu hotplug lock inversion
In reply to Sasha LevinFrom: Peter Zijlstra <[email protected]>
[ Upstream commit eabe06595d62cfa9278e2cd012df614bc68a7042 ]
By poking at /debug/sched_features I triggered the following splat:
[] ======================================================
[] WARNING: possible circular locking dependency detected
[] 4.11.0-00873-g964c8b7-dirty #694 Not tainted
[] ------------------------------------------------------
[] bash/2109 is trying to acquire lock:
[] (cpu_hotplug_lock.rw_sem){++++++}, at: [<ffffffff8120cb8b>] static_key_slow_dec+0x1b/0x50 []
[] but task is already holding lock:
[] (&sb->s_type->i_mutex_key#4){+++++.}, at: [<ffffffff81140216>] sched_feat_write+0x86/0x170 []
[] which lock already depends on the new lock.
[]
[]
[] the existing dependency chain (in reverse order) is:
[]
[] -> #2 (&sb->s_type->i_mutex_key#4){+++++.}:
[] lock_acquire+0x100/0x210
[] down_write+0x28/0x60
[] start_creating+0x5e/0xf0
[] debugfs_create_dir+0x13/0x110
[] blk_mq_debugfs_register+0x21/0x70
[] blk_mq_register_dev+0x64/0xd0
[] blk_register_queue+0x6a/0x170
[] device_add_disk+0x22d/0x440
[] loop_add+0x1f3/0x280
[] loop_init+0x104/0x142
[] do_one_initcall+0x43/0x180
[] kernel_init_freeable+0x1de/0x266
[] kernel_init+0xe/0x100
[] ret_from_fork+0x31/0x40
[]
[] -> #1 (all_q_mutex){+.+.+.}:
[] lock_acquire+0x100/0x210
[] __mutex_lock+0x6c/0x960
[] mutex_lock_nested+0x1b/0x20
[] blk_mq_init_allocated_queue+0x37c/0x4e0
[] blk_mq_init_queue+0x3a/0x60
[] loop_add+0xe5/0x280
[] loop_init+0x104/0x142
[] do_one_initcall+0x43/0x180
[] kernel_init_freeable+0x1de/0x266
[] kernel_init+0xe/0x100
[] ret_from_fork+0x31/0x40 [] *** DEADLOCK ***
[]
[] 3 locks held by bash/2109:
[] #0: (sb_writers#11){.+.+.+}, at: [<ffffffff81292bcd>] vfs_write+0x17d/0x1a0
[] #1: (debugfs_srcu){......}, at: [<ffffffff8155a90d>] full_proxy_write+0x5d/0xd0
[] #2: (&sb->s_type->i_mutex_key#4){+++++.}, at: [<ffffffff81140216>] sched_feat_write+0x86/0x170 []
[] stack backtrace:
[] CPU: 9 PID: 2109 Comm: bash Not tainted 4.11.0-00873-g964c8b7-dirty #694
[] Hardware name: Intel Corporation S2600GZ/S2600GZ, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013 [] Call Trace:
[] lock_acquire+0x100/0x210 [] get_online_cpus+0x2a/0x90 [] static_key_slow_dec+0x1b/0x50 [] static_key_disable+0x20/0x30 [] sched_feat_write+0x131/0x170 [] full_proxy_write+0x97/0xd0 [] __vfs_write+0x28/0x120 [] vfs_write+0xb5/0x1a0 [] SyS_write+0x49/0xa0 [] entry_SYSCALL_64_fastpath+0x23/0xc2
This is because of the cpu hotplug lock rework. Break the chain at #1 by reversing the lock acquisition order. This way i_mutex_key#4 no longer depends on cpu_hotplug_lock and things are good.
--- block/blk-mq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
block/blk-mq.c +2 -2
@@ -2014,15 +2014,15 @@ struct request_queue *blk_mq_init_allocated_queue(struct blk_mq_tag_set *set,blk_mq_init_cpu_queues (q, set->nr_hw_queues); -get_online_cpus ();mutex_lock (&all_q_mutex); +get_online_cpus ();list_add_tail (&q->all_q_node, &all_q_list);blk_mq_add_queue_tag_set (set, q);blk_mq_map_swqueue (q, cpu_online_mask); -mutex_unlock (&all_q_mutex);put_online_cpus (); +mutex_unlock (&all_q_mutex);return q;
Signature · 1 line
2.14.1
PATCH 152/190 Bluetooth: hci_qca: Avoid setup failure on missing rampatch
In reply to Sasha LevinFrom: Loic Poulain <[email protected]>
[ Upstream commit ba8f3597900291a93604643017fff66a14546015 ]
Assuming that the original code idea was to enable in-band sleeping only if the setup_rome method returns succes and run in 'standard' mode otherwise, we should not return setup_rome return value which makes qca_setup fail if no rampatch/nvm file found.
This fixes BT issue on the dragonboard-820C p4 which includes the following QCA controller:
hci0: Product:0x00000008
hci0: Patch :0x00000111
hci0: ROM :0x00000302
hci0: SOC :0x00000044
Since there is no rampatch for this controller revision, just make it work as is.
--- drivers/bluetooth/hci_qca.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/bluetooth/hci_qca.c +3 -0
@@ -936,6 +936,9 @@ static int qca_setup(struct hci_uart *hu)if (!ret) {set_bit (STATE_IN_BAND_SLEEP_ENABLED , &qca->flags);qca_debugfs_init (hdev); + }else if (ret == -ENOENT ) { +/* No patch/nvm-config found, run with original fw/config */ + ret =0 ; }/* Setup bdaddr */
Signature · 1 line
2.14.1
PATCH 153/190 Bluetooth: btqcomsmd: Fix skb double free corruption
In reply to Sasha LevinFrom: Loic Poulain <[email protected]>
[ Upstream commit 67b8fbead4685b36d290a0ef91c6ddffc4920ec9 ]
In case of hci send frame failure, skb is still owned by the caller (hci_core) and then should not be freed.
This fixes crash on dragonboard-410c when sending SCO packet. skb is freed by both btqcomsmd and hci_core.
--- drivers/bluetooth/btqcomsmd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/bluetooth/btqcomsmd.c +2 -1
@@ -85,7 +85,8 @@ static int btqcomsmd_send(struct hci_dev *hdev, struct sk_buff *skb)break ; } -kfree_skb (skb); +if (!ret) +kfree_skb (skb);return ret; }
Signature · 1 line
2.14.1
PATCH 154/190 media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt
In reply to Sasha LevinFrom: "Gustavo A. R. Silva" <[email protected]>
[ Upstream commit baed3c4bc4c13de93e0dba0a26d601411ebcb389 ]
_channel_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _channel_ has been null checked.
This issue was detected with the help of Coccinelle.
--- drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c +3 -1
@@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(unsigned long ac8sectpfei)static void channel_swdemux_tsklet (unsigned long data) {struct channel_info *channel = (struct channel_info *)data; -struct c8sectpfei *fei = channel->fei; +struct c8sectpfei *fei;unsigned long wp, rp;int pos, num_packets, n, size;u8 *buf;
@@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsigned long data)if (unlikely (!channel || !channel->irec))return ; + fei = channel->fei; + wp =readl (channel->irec +DMA_PRDS_BUSWP_TP (0 )); rp =readl (channel->irec +DMA_PRDS_BUSRP_TP (0 ));
Signature · 1 line
2.14.1
PATCH 155/190 drm/msm: fix leak in failed get_pages
In reply to Sasha LevinFrom: Prakash Kamliya <[email protected]>
[ Upstream commit 62e3a3e342af3c313ab38603811ecdb1fcc79edb ]
get_pages doesn't keep a reference of the pages allocated when it fails later in the code path. This can lead to a memory leak. Keep reference of the allocated pages so that it can be freed when msm_gem_free_object gets called later during cleanup.
--- drivers/gpu/drm/msm/msm_gem.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
drivers/gpu/drm/msm/msm_gem.c +10 -4
@@ -91,14 +91,17 @@ static struct page **get_pages(struct drm_gem_object *obj)return p; } + msm_obj->pages = p; + msm_obj->sgt =drm_prime_pages_to_sg (p, npages);if (IS_ERR (msm_obj->sgt)) { +void *ptr =ERR_CAST (msm_obj->sgt); +dev_err (dev->dev,"failed to allocate sgt\n" ); -return ERR_CAST (msm_obj->sgt); + msm_obj->sgt =NULL ; +return ptr; } - msm_obj->pages = p; -/* For non-cached buffers, ensure the new pages are clean * because display controller, GPU, etc. are not coherent: */
@@ -121,7 +124,10 @@ static void put_pages(struct drm_gem_object *obj)if (msm_obj->flags & (MSM_BO_WC |MSM_BO_UNCACHED ))dma_unmap_sg (obj->dev->dev, msm_obj->sgt->sgl, msm_obj->sgt->nents,DMA_BIDIRECTIONAL ); -sg_free_table (msm_obj->sgt); + +if (msm_obj->sgt) +sg_free_table (msm_obj->sgt); +kfree (msm_obj->sgt);if (use_pages (obj))
Signature · 1 line
2.14.1
PATCH 156/190 dm: ensure bio submission follows a depth-first tree walk
In reply to Sasha LevinFrom: NeilBrown <[email protected]>
[ Upstream commit 18a25da84354c6bb655320de6072c00eda6eb602 ]
A dm device can, in general, represent a tree of targets, each of which handles a sub-range of the range of blocks handled by the parent.
The bio sequencing managed by generic_make_request() requires that bios are generated and handled in a depth-first manner. Each call to a make_request_fn() may submit bios to a single member device, and may submit bios for a reduced region of the same device as the make_request_fn.
In particular, any bios submitted to member devices must be expected to be processed in order, so a later one must never wait for an earlier one.
This ordering is usually achieved by using bio_split() to reduce a bio to a size that can be completely handled by one target, and resubmitting the remainder to the originating device. bio_queue_split() shows the canonical approach.
dm doesn't follow this approach, largely because it has needed to split bios since long before bio_split() was available. It currently can submit bios to separate targets within the one dm_make_request() call. Dependencies between these targets, as can happen with dm-snap, can cause deadlocks if either bios gets stuck behind the other in the queues managed by generic_make_request(). This requires the 'rescue' functionality provided by dm_offload_{start,end}.
Some of this requirement can be removed by changing the order of bio submission to follow the canonical approach. That is, if dm finds that it needs to split a bio, the remainder should be sent to generic_make_request() rather than being handled immediately. This delays the handling until the first part is completely processed, so the deadlock problems do not occur.
__split_and_process_bio() can be called both from dm_make_request() and from dm_wq_work(). When called from dm_wq_work() the current approach is perfectly satisfactory as each bio will be processed immediately. When called from dm_make_request(), current->bio_list will be non-NULL, and in this case it is best to create a separate "clone" bio for the remainder.
When we use bio_clone_bioset() to split off the front part of a bio and chain the two together and submit the remainder to generic_make_request(), it is important that the newly allocated bio is used as the head to be processed immediately, and the original bio gets "bio_advance()"d and sent to generic_make_request() as the remainder. Otherwise, if the newly allocated bio is used as the remainder, and if it then needs to be split again, then the next bio_clone_bioset() call will be made while holding a reference a bio (result of the first clone) from the same bioset. This can potentially exhaust the bioset mempool and result in a memory allocation deadlock.
Note that there is no race caused by reassigning cio.io->bio after already calling __map_bio(). This bio will only be dereferenced again after dec_pending() has found io->io_count to be zero, and this cannot happen before the dec_pending() call at the end of __split_and_process_bio().
To provide the clone bio when splitting, we use q->bio_split. This was previously being freed by bio-based dm to avoid having excess rescuer threads. As bio_split bio sets no longer create rescuer threads, there is little cost and much gain from restoring the q->bio_split bio set.
--- drivers/md/dm.c | 33 ++++++++++++++++++++++++--------- 1 file changed, 24 insertions(+), 9 deletions(-)
drivers/md/dm.c +24 -9
@@ -1320,8 +1320,29 @@ static void __split_and_process_bio(struct mapped_device *md, }else { ci.bio = bio; ci.sector_count =bio_sectors (bio); -while (ci.sector_count && !error) +while (ci.sector_count && !error) { error =__split_and_process_non_flush (&ci); +if (current->bio_list && ci.sector_count && !error) { +/* +* Remainder must be passed to generic_make_request() +* so that it gets handled *after* bios already submitted +* have been completely processed. +* We take a clone of the original to store in +* ci.io->bio to be used by end_io_acct() and +* for dec_pending to use for completion handling. +* As this path is not used for REQ_OP_ZONE_REPORT, +* the usage of io->bio in dm_remap_zone_report() +* won't be affected by this reassignment. +*/ +struct bio *b =bio_clone_bioset (bio,GFP_NOIO , + md->queue->bio_split); + ci.io->bio = b; +bio_advance (bio, (bio_sectors (bio) - ci.sector_count) <<9 ); +bio_chain (b, bio); +generic_make_request (bio); +break ; + } + } }/* drop the extra reference count */
@@ -1332,8 +1353,8 @@ static void __split_and_process_bio(struct mapped_device *md,*---------------------------------------------------------------*/ /* -* The request function that just remaps the bio built up by -* dm_merge_bvec. +* The request function that remaps the bio to one target and +* splits off any remainder. */ static blk_qc_t dm_make_request (struct request_queue *q,struct bio *bio) {
@@ -1854,12 +1875,6 @@ int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t)case DM_TYPE_DAX_BIO_BASED :dm_init_normal_md_queue (md);blk_queue_make_request (md->queue, dm_make_request); -/* -* DM handles splitting bios as needed. Free the bio_split bioset -* since it won't be used (saves 1 process per bio-based DM device). -*/ -bioset_free (md->queue->bio_split); - md->queue->bio_split =NULL ;if (type ==DM_TYPE_DAX_BIO_BASED )queue_flag_set_unlocked (QUEUE_FLAG_DAX , md->queue);
Signature · 1 line
2.14.1
PATCH 157/190 RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo()
In reply to Sasha LevinFrom: Geert Uytterhoeven <[email protected]>
[ Upstream commit 302d6424e4a293a5761997e6c9fc3dfb1e4c355f ]
With gcc-4.1.2:
drivers/infiniband/core/iwpm_util.c: In function ‘iwpm_send_mapinfo’:
drivers/infiniband/core/iwpm_util.c:647: warning: ‘ret’ may be used uninitialized in this function
Indeed, if nl_client is not found in any of the scanned has buckets, ret will be used uninitialized.
Preinitialize ret to -EINVAL to fix this.
--- drivers/infiniband/core/iwpm_util.c | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/core/iwpm_util.c +1 -0
@@ -664,6 +664,7 @@ int iwpm_send_mapinfo(u8 nl_client, int iwpm_pid) } skb_num++;spin_lock_irqsave (&iwpm_mapinfo_lock, flags); + ret = -EINVAL ;for (i =0 ; i <IWPM_MAPINFO_HASH_SIZE ; i++) {hlist_for_each_entry (map_info, &iwpm_hash_bucket[i], hlist_node) {
Signature · 1 line
2.14.1
PATCH 158/190 rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.
In reply to Sasha LevinFrom: Tsang-Shian Lin <[email protected]>
[ Upstream commit b7573a0a27bfa8270dea9b145448f6884b7cacc1 ]
Reset the driver current tx read/write index to zero when inactiveps nic out of sync with HW state. Wrong driver tx read/write index will cause Tx fail.
--- drivers/net/wireless/realtek/rtlwifi/pci.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/wireless/realtek/rtlwifi/pci.c +7 -0
@@ -1572,7 +1572,14 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)dev_kfree_skb_irq (skb); ring->idx = (ring->idx +1 ) % ring->entries; } + +if (rtlpriv->use_new_trx_flow) { + rtlpci->tx_ring[i].cur_tx_rp =0 ; + rtlpci->tx_ring[i].cur_tx_wp =0 ; + } + ring->idx =0 ; + ring->entries = rtlpci->txringcount[i]; } }spin_unlock_irqrestore (&rtlpriv->locks.irq_th_lock, flags);
Signature · 1 line
2.14.1
PATCH 159/190 media: bt8xx: Fix err 'bt878_probe()'
In reply to Sasha LevinFrom: Christophe JAILLET <[email protected]>
[ Upstream commit 45392ff6881dbe56d41ef0b17c2e576065f8ffa1 ]
This is odd to call 'pci_disable_device()' in an error path before a coresponding successful 'pci_enable_device()'.
Return directly instead.
--- drivers/media/pci/bt8xx/bt878.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/media/pci/bt8xx/bt878.c +1 -2
@@ -422,8 +422,7 @@ static int bt878_probe(struct pci_dev *dev, const struct pci_device_id *pci_id) bt878_num);if (bt878_num >=BT878_MAX ) {printk (KERN_ERR "bt878: Too many devices inserted\n" ); - result = -ENOMEM ; - goto fail0; +return -ENOMEM ; }if (pci_enable_device (dev))return -EIO ;
Signature · 1 line
2.14.1
PATCH 160/190 ath10k: handling qos at STA side based on AP WMM enable/disable
In reply to Sasha LevinFrom: Balaji Pothunoori <[email protected]>
[ Upstream commit 07ffb4497360ae8789f05555fec8171ee952304d ]
Data packets are not sent by STA in case of STA joined to non QOS AP (WMM disabled AP). This is happening because of STA is sending data packets to firmware from host with qos enabled along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.
This patch fixes this issue by updating the qos based on station WME capability field if WMM is disabled in AP.
This patch is required by 10.4 family chipsets like QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.
For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch has no effect.
--- drivers/net/wireless/ath/ath10k/mac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/ath/ath10k/mac.c +1 -1
@@ -2505,7 +2505,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar, }break ;case WMI_VDEV_TYPE_STA : -if (vif->bss_conf.qos) +if (sta->wme) arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;break ;case WMI_VDEV_TYPE_IBSS :
Signature · 1 line
2.14.1
PATCH 161/190 media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart
In reply to Sasha LevinFrom: Ron Economos <[email protected]>
[ Upstream commit 380a6c86457573aa42d27ae11e025eb25941a0b7 ]
On faster CPUs a delay is required after the resume command and the restart command. Without the delay, the restart command often returns -EREMOTEIO and the Si2168 does not restart.
Note that this patch fixes the same issue as https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix addresses the actual problem.
--- drivers/media/dvb-frontends/si2168.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/media/dvb-frontends/si2168.c +3 -0
@@ -14,6 +14,8 @@* GNU General Public License for more details. */ +#include <linux/delay.h> +#include "si2168_priv.h" static const struct dvb_frontend_ops si2168_ops;
@@ -378,6 +380,7 @@ static int si2168_init(struct dvb_frontend *fe)if (ret) goto err; +udelay (100 );memcpy (cmd.args,"\x85" ,1 ); cmd.wlen =1 ; cmd.rlen =1 ;
Signature · 1 line
2.14.1
PATCH 162/190 qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect
In reply to Sasha LevinFrom: Bjørn Mork <[email protected]>
[ Upstream commit 245d21190aec547c0de64f70c0e6de871c185a24 ]
It has been reported that the dummy byte we add to avoid ZLPs can be forwarded by the modem to the PGW/GGSN, and that some operators will drop the connection if this happens.
In theory, QMI devices are based on CDC ECM and should as such both support ZLPs and silently ignore the dummy byte. The latter assumption failed. Let's test out the first.
--- drivers/net/usb/qmi_wwan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/usb/qmi_wwan.c +2 -2
@@ -531,7 +531,7 @@ static int qmi_wwan_resume(struct usb_interface *intf)static const struct driver_info qmi_wwan_info = { .description ="WWAN/QMI device" , - .flags =FLAG_WWAN , + .flags =FLAG_WWAN |FLAG_SEND_ZLP , .bind = qmi_wwan_bind, .unbind = qmi_wwan_unbind, .manage_power = qmi_wwan_manage_power,
@@ -540,7 +540,7 @@ static const struct driver_info qmi_wwan_info = {static const struct driver_info qmi_wwan_info_quirk_dtr = { .description ="WWAN/QMI device" , - .flags =FLAG_WWAN , + .flags =FLAG_WWAN |FLAG_SEND_ZLP , .bind = qmi_wwan_bind, .unbind = qmi_wwan_unbind, .manage_power = qmi_wwan_manage_power,
Signature · 1 line
2.14.1
PATCH 163/190 serial: 8250_dw: Disable clock on error
In reply to Sasha LevinFrom: Stefan Potyra <[email protected]>
[ Upstream commit 8af016aa5a27c6a2505460eb4d83f1e70c38dc43 ]
If there is no clock rate for uartclk defined, disable the previously enabled clock again.
Found by Linux Driver Verification project (linuxtesting.org).
--- drivers/tty/serial/8250/8250_dw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/tty/serial/8250/8250_dw.c +2 -1
@@ -464,7 +464,8 @@ static int dw8250_probe(struct platform_device *pdev)/* If no clock rate is defined, fail. */ if (!p->uartclk) {dev_err (dev,"clock rate not defined\n" ); -return -EINVAL ; + err = -EINVAL ; + goto err_clk; } data->pclk =devm_clk_get (dev,"apb_pclk" );
Signature · 1 line
2.14.1
PATCH 164/190 cros_ec: fix nul-termination for firmware build info
In reply to Sasha LevinFrom: Arnd Bergmann <[email protected]>
[ Upstream commit 50a0d71a5d20e1d3eff1d974fdc8559ad6d74892 ]
As gcc-8 reports, we zero out the wrong byte:
drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]
This changes the code back to what it did before changing to a zero-length array structure.
--- drivers/platform/chrome/cros_ec_sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/platform/chrome/cros_ec_sysfs.c +1 -1
@@ -187,7 +187,7 @@ static ssize_t show_ec_version(struct device *dev, count +=scnprintf (buf + count,PAGE_SIZE - count,"Build info: EC error %d\n" , msg->result); else { - msg->data[sizeof (msg->data) -1 ] ='\0' ; + msg->data[EC_HOST_PARAM_SIZE -1 ] ='\0' ; count +=scnprintf (buf + count,PAGE_SIZE - count,"Build info: %s\n" , msg->data); }
Signature · 1 line
2.14.1
PATCH 165/190 watchdog: Fix potential kref imbalance when opening watchdog
In reply to Sasha LevinFrom: Guenter Roeck <[email protected]>
[ Upstream commit 4bcd615fad6adddc68b058d498b30a9e0e0db77a ]
If a watchdog driver's open function sets WDOG_HW_RUNNING with the expectation that the watchdog can not be stopped, but then stops the watchdog anyway in its stop function, kref_get() wil not be called in watchdog_open(). If the watchdog then stops on close, WDOG_HW_RUNNING will be cleared and kref_put() will be called, causing a kref imbalance. As result the character device data structure will be released, which in turn will cause the system to crash on the next call to watchdog_open().
--- drivers/watchdog/watchdog_dev.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/watchdog/watchdog_dev.c +4 -2
@@ -760,6 +760,7 @@ static int watchdog_open(struct inode *inode, struct file *file) {struct watchdog_core_data *wd_data;struct watchdog_device *wdd; +bool hw_running;int err;/* Get the corresponding watchdog device */
@@ -779,7 +780,8 @@ static int watchdog_open(struct inode *inode, struct file *file)* If the /dev/watchdog device is open, we don't want the module * to be unloaded. */ -if (!watchdog_hw_running (wdd) && !try_module_get (wdd->ops->owner)) { + hw_running =watchdog_hw_running (wdd); +if (!hw_running && !try_module_get (wdd->ops->owner)) { err = -EBUSY ; goto out_clear; }
@@ -790,7 +792,7 @@ static int watchdog_open(struct inode *inode, struct file *file) file->private_data = wd_data; -if (!watchdog_hw_running (wdd)) +if (!hw_running)kref_get (&wd_data->kref);/* dev/watchdog is a virtual (and thus non-seekable) filesystem */
Signature · 1 line
2.14.1
PATCH 166/190 platform/chrome: Use proper protocol transfer function
In reply to Sasha LevinFrom: Shawn Nematbakhsh <[email protected]>
[ Upstream commit d48b8c58c57f6edbe2965f0a5f62c5cf9593ca96 ]
pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had one instance of these functions correct, but not the second, fall-back case. We use the fall-back only when the first command returns an IN_PROGRESS status, which is only used on some EC firmwares where we don't want to constantly poll the bus, but instead back off and sleep/retry for a little while.
--- drivers/platform/chrome/cros_ec_proto.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/platform/chrome/cros_ec_proto.c +5 -3
@@ -60,12 +60,14 @@ static int send_command(struct cros_ec_device *ec_dev, struct cros_ec_command *msg) {int ret; +int (*xfer_fxn)(struct cros_ec_device *ec,struct cros_ec_command *msg);if (ec_dev->proto_version >2 ) - ret = ec_dev->pkt_xfer (ec_dev, msg); + xfer_fxn = ec_dev->pkt_xfer;else - ret = ec_dev->cmd_xfer (ec_dev, msg); + xfer_fxn = ec_dev->cmd_xfer; + ret = (*xfer_fxn)(ec_dev, msg);if (msg->result ==EC_RES_IN_PROGRESS ) {int i;struct cros_ec_command *status_msg;
@@ -88,7 +90,7 @@ static int send_command(struct cros_ec_device *ec_dev,for (i =0 ; i <EC_COMMAND_RETRIES ; i++) {usleep_range (10000 ,11000 ); - ret = ec_dev->cmd_xfer (ec_dev, status_msg); + ret = (*xfer_fxn)(ec_dev, status_msg);if (ret <0 )break ;
Signature · 1 line
2.14.1
PATCH 167/190 dmaengine: zynqmp_dma: Fix race condition in the probe
In reply to Sasha LevinFrom: Kedareswara rao Appana <[email protected]>
[ Upstream commit 5ba080aada5e739165e0f38d5cc3b04c82b323c8 ]
Incase of interrupt property is not present,
Driver is trying to free an invalid irq,
This patch fixes it by adding a check before freeing the irq.
--- drivers/dma/xilinx/zynqmp_dma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/dma/xilinx/zynqmp_dma.c +2 -1
@@ -933,7 +933,8 @@ static void zynqmp_dma_chan_remove(struct zynqmp_dma_chan *chan)if (!chan)return ; -devm_free_irq (chan->zdev->dev, chan->irq, chan); +if (chan->irq) +devm_free_irq (chan->zdev->dev, chan->irq, chan);tasklet_kill (&chan->tasklet);list_del (&chan->common.device_node);clk_disable_unprepare (chan->clk_apb);
Signature · 1 line
2.14.1
PATCH 168/190 drm/tilcdc: ensure nonatomic iowrite64 is not used
In reply to Sasha LevinFrom: Logan Gunthorpe <[email protected]>
[ Upstream commit 4e5ca2d930aa8714400aedf4bf1dc959cb04280f ]
Add a check to ensure iowrite64 is only used if it is atomic.
It was decided in [1] that the tilcdc driver should not be using an atomic operation (so it was left out of this patchset). However, it turns out that through the drm code, a nonatomic header is actually included:
include/linux/io-64-nonatomic-lo-hi.h
is included from include/drm/drm_os_linux.h:9:0,
from include/drm/drmP.h:74,
from include/drm/drm_modeset_helper.h:26,
from include/drm/drm_atomic_helper.h:33,
from drivers/gpu/drm/tilcdc/tilcdc_crtc.c:19:And thus, without this change, this patchset would inadvertantly change the behaviour of the tilcdc driver.
[1] lkml.kernel.org/r/CAK8P3a2HhO_zCnsTzq7hmWSz5La5Thu19FWZpun16iMnyyNreQ@mail.gmail.com
--- drivers/gpu/drm/tilcdc/tilcdc_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/tilcdc/tilcdc_regs.h +1 -1
@@ -124,7 +124,7 @@ static inline void tilcdc_write64(struct drm_device *dev, u32 reg, u64 data)struct tilcdc_drm_private *priv = dev->dev_private;volatile void __iomem *addr = priv->mmio + reg; -#ifdef iowrite64 +#if defined(iowrite64) && !defined(iowrite64_is_nonatomic)iowrite64 (data, addr);#else __iowmb ();
Signature · 1 line
2.14.1
PATCH 169/190 mmc: avoid removing non-removable hosts during suspend
In reply to Sasha LevinFrom: Daniel Drake <[email protected]>
[ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ]
The Weibu F3C MiniPC has an onboard AP6255 module, presenting two SDIO functions on a single MMC host (Bluetooth/btsdio and WiFi/brcmfmac), and the mmc layer correctly detects this as non-removable.
After suspend/resume, the wifi and bluetooth interfaces disappear and do not get probed again.
The conditions here are:
1. During suspend, we reach mmc_pm_notify()
2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can suspend the SDIO host. However, mmc_sdio_pre_suspend() returns -ENOSYS because btsdio_driver does not have a suspend method.
3. mmc_pm_notify() proceeds to remove the card
4. Upon resume, mmc_rescan() does nothing with this host, because of the rescan_entered check which aims to only scan a non-removable device a single time (i.e. during boot).
Fix the loss of functionality by detecting that we are unable to suspend a non-removable host, so avoid the forced removal in that case. The comment above this function already indicates that this code was only intended for removable devices.
--- drivers/mmc/core/core.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/mmc/core/core.c +8 -0
@@ -2974,6 +2974,14 @@ static int mmc_pm_notify(struct notifier_block *notify_block,if (!err)break ; +if (!mmc_card_is_removable (host)) { +dev_warn (mmc_dev (host), +"pre_suspend failed for non-removable host: " +"%d\n" , err); +/* Avoid removing non-removable hosts */ +break ; + } +/* Calling bus_ops->remove() with a claimed host can deadlock */ host->bus_ops->remove (host);mmc_claim_host (host);
Signature · 1 line
2.14.1