Tushar Dave [Thu, 10 Dec 2015 01:16:25 +0000 (17:16 -0800)]
i40e: Temporary workaround for DMA map issue
This is a quick temporary workaround for Bug 22107931.
iommu DMA map failure occurs when i40e saturate iommu with large number
of DMA map requests. e.g. System running 128 CPUs can maximum have 256K-1
entries in iommu table considering 8K page size and 32bit iommu (i.e.
2^31/PAGE_SIZE). On this system, i40e driver by default has 128 Queue Pairs
(QP) per interface. For each Rx queues, i40e by default, allocates 512 Rx
buffers which generates 64K DMA map requests. Four i40e interfaces will
generates total of 256K DMA map requests. That is beyond iommu can
accommodate and therefor results into DMA map failure.
The correct fix would be that i40e driver should not saturate iommu
resources and graciously bailout when DMA map failure occurs.
However, due severity of the issue and complexity involved implementing
correct resolution, this patch provides quick temporary workaround by
just limiting number of QP not to exceed 32.
For the record, QP equals 32 chosen because QP has to be power of 2 and we
can't have QP equals 64 because in that case number of DMA map requests for
Rx and Tx will be 256K and iommu can only accommodate 256K-1.
i.e.
64 RX queues * 512 RX buffers = 32K , for 4 interfaces = 128K
64 TX queues * 512 TX buffers = 32K , for 4 interfaces = 128K
When an appropriate fix (as mentioned above) is ready, this quick temporary
workaround will be removed.
Note:this temporary workaround can have negative impact on i40e network
performance.
Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com>
Aaron Young [Thu, 10 Dec 2015 14:39:54 +0000 (06:39 -0800)]
SPARC64: UEK4 LDOMS DOMAIN SERVICES UPDATE 2
This update provides fixes for LDom domain services on UEK4.
Including:
1. Add control vlds device for non-device specific operations.
2. Allocate larger LDC rx/tx queues based on MTU - same
algorithm as Solaris.
3. Fix default MTU for all ds devices to 4096 bytes.
If the macaddr is not from Open Firmwre or IDPROM (i.e., defaults
macaddr was used) then do not call i40e_macaddr_init again, else
you will get a driver init failure like this:
Babu Moger [Thu, 3 Dec 2015 18:24:38 +0000 (10:24 -0800)]
drivers/pci: Update the quirks for megaraid_sas adapter
This megaraid_sas adapter does have a valid pci vpd information.
Earlier commit 5bf1badcd02f ("pci: Limit VPD length for megaraid_sas
adapter") changed the vpd length to 0x80. This change fixed the panic.
However, we found some options of the lspci does not work very well if
it cannot find the valid vpd tag(Example command "lspci -s 10:00.0 -vv").
It displays the error message and exits right away. Setting the length
to 0 fixes the problem.
Srikar Dronamraju [Wed, 24 Jun 2015 11:10:04 +0000 (16:40 +0530)]
perf bench numa: Fix to show proper convergence stats
With commit: e1e455f4f4d3 (perf tools: Work around lack of sched_getcpu
in glibc < 2.6), perf_bench numa mem with -c or -m option is not able to
correctly calculate convergence.
With the above commit, sched_getcpu always seems to return -1. The
intention of commit e1e455f was to add a sched_getcpu in glibc < 2.6.
Hence keep the sched_getcpu definition under an ifdef.
This regression happened occurred between v4.0 and v4.1
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Vinson Lee <vlee@twitter.com> Fixes: e1e455f4f4d3 ("perf tools: Work around lack of sched_getcpu in glibc < 2.6") Link: http://lkml.kernel.org/r/20150624111004.GA5220@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
(cherry picked from commit 2b42b09b88c831ba4da2d669581dde371c38c2af)
Dan Williams [Thu, 12 Nov 2015 20:13:57 +0000 (12:13 -0800)]
ALSA: pci: depend on ZONE_DMA
There are several sound drivers that 'select ZONE_DMA'. This is
backwards as ZONE_DMA is an architecture capability exported to drivers.
Switch the polarity of the dependency to disable these drivers when the
architecture does not support ZONE_DMA. This was discovered in the
context of testing/enabling devm_memremap_pages() which depends on
ZONE_DEVICE. ZONE_DEVICE in turn depends on !ZONE_DMA.
Reported-by: Jeff Moyer <jmoyer@redhat.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 2db1a57986d37653583e67ccbf13082aadc8f25d)
Babu Moger [Fri, 6 Nov 2015 22:11:01 +0000 (17:11 -0500)]
pci: Limit VPD length for megaraid_sas adapter
Reading or Writing of PCI VPD data causes system panic.
We saw this problem by running "lspci -vvv" in the beginning.
However this can be easily reproduced by running
cat /sys/bus/devices/XX../vpd
VPD length has been set as 32768 by default. Accessing vpd
will trigger read/write of 32k. This causes problem as we
could read data beyond the VPD end tag. Behaviour is un-
predictable when this happens. I see some other adapter doing
similar quirks(commit bffadffd43d4 ("PCI: fix VPD limit quirk
for Broadcom 5708S"))
I see there is an attempt to fix this right way.
https://patchwork.ozlabs.org/patch/534843/ or
https://lkml.org/lkml/2015/10/23/97
Tried to fix it this way, but problem is I dont see the proper
start/end TAGs(at least for this adapter) at all. The data is
mostly junk or zeros. This patch fixes the issue by setting the
vpd length to 0x80.
Signed-off-by: Babu Moger <babu.moger@oracle.com> Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com>
Orabug: 22104511
Changes since v2 -> v3
Changed the vpd length from 0 to 0x80 which leaves the
option open for someone to read first few bytes.
Changes since v1 -> v2
Removed the changes in pci_id.h. Kept all the vendor
ids in quirks.c
(cherry picked from commit 8b95aa6b57dd64c4f36fa74026afe62de8c3afbb)
Aaron Young [Wed, 11 Nov 2015 14:24:54 +0000 (06:24 -0800)]
SPARC64: UEK4 LDOMS DOMAIN SERVICES UPDATE 1
This update provides several fixes for LDoms on UEK4
(i.e. fixes/updates for the ldoms UEK4 port done previously
- See BUG 21644721) and updates for ldoms to work with Zeus.
It also provides support for libpri which requires a HV call
to retrieve the PRI from the SP and enhancements to the vlds
driver to allow multiple process to register/use a service
simultaneously - so multiple processes can use libpri at the
same time.
Sowmini Varadhan [Wed, 4 Nov 2015 19:39:56 +0000 (14:39 -0500)]
i40e: Look up MAC address in Open Firmware or IDPROM
This is the i40e equivalent of commit c762dff24c06 ("ixgbe: Look up MAC
address in Open Firmware or IDPROM").
As with that fix, attempt to look up the MAC address in Open Firmware
on systems that support it, and use IDPROM on SPARC if no OF address
is found.
In the case of the i40e there is an assumption that the default mac
address has already been set up as the primary mac filter on probe,
so if this filter is obtained from the Open Firmware or IDPROM, an
explicit write is needed via i40e_aq_mac_address_write() and
i40e_aq_add_macvlan() invocation.
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
(cherry picked from commit c7a3fd4e5d009b6b5bc90ee373aac232a7089068)
Nick Alcock [Mon, 2 Nov 2015 21:44:27 +0000 (21:44 +0000)]
sparc64, vdso: update the CLOCK_MONOTONIC_COARSE clock
In the significant rewrite involved in porting the SPARC vDSO code to
v4.1, the CLOCK_MONOTONIC_COARSE clock moved from being computed from
the CLOCK_REALTIME variable in the vvar page to being tracked by its own
vvar (mirroring a similar change done for x86): this vvar is maintained
in the same way, but is derived only once per jiffy tick rather than
every time clock_gettime() is called, which is likely faster under
sufficiently insane clock_gettime() than the way we did it in v3.0.
Unfortunately, the code to maintain this variable in
arch/sparc/kernel/vsyscall_gtod.c was never implemented, so
clock_gettime(CLOCK_MONOTONIC_COARSE) always returns zero. This is a
little coarser than the user would probably like.
Easily fixed by updating the relevant vvar in the same way as is done on
x86.
Reported-by: Wim Coekaerts <wim.coekaerts@oracle.com> Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Dave Kleikamp <dave.kleikamp@oracle.com> Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Orabug: 22137842
Allen Pais [Tue, 20 Oct 2015 18:42:59 +0000 (00:12 +0530)]
sparc: Accommodate mem64_offset != mem_offset in pbm configuration
PCI specs do not require mem_offset to be the same as mem64_offset.
This patch adds code to handle the cases where they are not the same
instead of panic'ing the kernel.
Yinghai Lu [Thu, 8 Oct 2015 21:38:34 +0000 (14:38 -0700)]
PCI: Restore pref MMIO allocation logic for host bridge without mmio64
From 5b2854155 (PCI: Restrict 64-bit prefetchable bridge windows to 64-bit
resources), we change the logic for pref mmio allocation:
When bridge pref support mmio64, we will only put children pref
that support mmio64 into it, and will put children pref mmio32
into bridge's non-pref mmio32.
That could leave bridge pref bar not used when that pref bar is mmio64,
and children res only has mmio32.
Also could have allocation failure when non-pref mmio32 is not big
enough space for those children pref mmio32.
That is not rational when the host bridge does not 64bit mmio above 4g
at all.
The patch restore to old logic:
when host bridge does not have has_mem64, put children pref mmio64 and
pref mmio32 all under bridges pref bars.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Orabug: 21826746
Yinghai Lu [Thu, 8 Oct 2015 21:38:32 +0000 (14:38 -0700)]
PCI: Add has_mem64 for struct host_bridge
Add has_mem64 for struct host_bridge, on root bus that does not support
mmio64 above 4g, will not set that.
We will use that info next two following patches:
1. Don't treat non-pref mmio64 as pref mmio, so will not put
it under bridge's pref range when rescan the devices
2. will keep pref mmio64 and pref mmio32 under bridge pref bar.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Orabug: 21826746
Yinghai Lu [Thu, 8 Oct 2015 21:38:31 +0000 (14:38 -0700)]
PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64
If any bridge up to root only have 32bit pref mmio, We don't need to
treat device non-pref mmio64 as as pref mmio64.
We need to move pci_bridge_check_ranges calling early.
for parent bridges pref mmio BAR may not allocated by BIOS, res flags
is still 0, we need to have it correct set before we check them for
child device resources.
-v2: check all bus resources instead of just res[15].
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Orabug: 21826746
All the bridges 64-bit resource have pref bit, but the device resource does not
have pref set, then we can not find parent for the device resource,
as we can not put non-pref mem under pref mem.
According to pcie spec errta
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13, in some case it is ok to mark some as pref.
Mark if the entire path from the host to the adapter is over PCI Express.
Then set pref compatible bit for claim/sizing/assign for 64bit mem resource
on that pcie device.
-v2: set pref for mmio 64 when whole path is PCI Express, according to David Miller.
-v3: don't set pref directly, change to UNDER_PREF, and set PREF before
sizing and assign resource, and cleart PREF afterwards. requested by BenH.
-v4: use on_all_pcie_path device flag instead.
Yinghai Lu [Thu, 8 Oct 2015 21:38:29 +0000 (14:38 -0700)]
OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource
For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource, so set
IORESOUCE_MEM_64 for 64bit resource during OF device resource flags
parsing.
Yinghai Lu [Thu, 8 Oct 2015 21:38:26 +0000 (14:38 -0700)]
PCI: kill wrong quirk about M7101
Meelis reported that qla2000 driver does not get loaded on one sparc system.
schizo f00732d0: PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [io 0x7fe01000000-0x7fe01ffffff] (bus address [0x0000-0xffffff])
pci 0001:00:06.0: quirk: [io 0x7fe01000800-0x7fe0100083f] claimed by ali7101 ACPI
pci 0001:00:06.0: quirk: [io 0x7fe01000600-0x7fe0100061f] claimed by ali7101 SMB
pci 0001:00:07.0: can't claim BAR 0 [io 0x7fe01000000-0x7fe0100ffff]: address conflict with 0001:00:06.0 [io 0x7fe01000600-0x7fe0100061f]
So the quirk for M7101 claim the io range early.
According to spec with M7101 in M1543 page 103/104,
http://www.versalogic.com/Support/Downloads/pdf/ali1543.pdf
0xe0, and 0xe2 do not include address info for acpi/smb.
and we already had pref_compat support that add extra pref bit for device
resource.
It turns out that pci_resource_compatible()/pci_up_path_over_pref_mem64()
just check resource with bridge pref mmio register idx 15, and we have put
resource to use mmio register idx 14 during of_scan_pci_bridge()
as the bridge does not mmio resource.
We already fix pci_up_path_over_pref_mem64() to check all bus resources.
And at the same time, this patch will make resource to consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even non-pref mmio is missing, or out of ordering in firmware reporting.
So hold i = 1 for non pref mmio, and i =2 for pref mmio.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Orabug: 21826746
Yinghai Lu [Thu, 8 Oct 2015 21:38:24 +0000 (14:38 -0700)]
sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource, so set
IORESOUCE_MEM_64 for 64bit resource during of device resource flags
parsing.
Yinghai Lu [Thu, 8 Oct 2015 21:38:20 +0000 (14:38 -0700)]
sparc/PCI: Add mem64 resource parsing for root bus
Found "no compatible bridge window" warning in boot log from T5-8.
pci 0000:00:01.0: can't claim BAR 15 [mem 0x100000000-0x4afffffff pref]: no compatible bridge window
That resource is above 4G, but does not get offset correctly as
root bus only report io and mem32.
pci_sun4v f02dbcfc: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x804000000000-0x80400fffffff] (bus address [0x0000-0xfffffff])
pci_bus 0000:00: root bus resource [mem 0x800000000000-0x80007effffff] (bus address [0x00000000-0x7effffff])
pci_bus 0000:00: root bus resource [bus 00-77]
Add mem64 handling in pci_common for sparc, so we can have 64bit resource
registered for root bus at first.
After patch, will have:
pci_sun4v f02dbcfc: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x804000000000-0x80400fffffff] (bus address [0x0000-0xfffffff])
pci_bus 0000:00: root bus resource [mem 0x800000000000-0x80007effffff] (bus address [0x00000000-0x7effffff])
pci_bus 0000:00: root bus resource [mem 0x800100000000-0x8007ffffffff] (bus address [0x100000000-0x7ffffffff])
pci_bus 0000:00: root bus resource [bus 00-77]
-v2: mem64_space should use mem_space.start as offset.
-v3: add IORESOURCE_MEM_64 flag
-v4: set name for mem64_space, otherwise /proc/iomem will have <bad> for name
Some of the crypto algorithms write to the IV (initialization vector),
but no space has been allocated for it. This results in memory
corruption and a kernel trap.
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
`ls /sys/devices/channel-devices/vnet-port-0-0/net' is missing without
this change, and applications like NetworkManager are looking in
sysfs for the information.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
lib/iommu-common.c: do not try to deref a null iommu->lazy_flush() pointer when n < pool->hint
The check for invoking iommu->lazy_flush() from iommu_tbl_range_alloc()
has to be refactored so that we only call ->lazy_flush() if it is
non-null.
I had a sparc kernel that was crashing when I was trying to process
some very large perf.data files- the crash happens when the scsi
driver calls into dma_4v_map_sg and thus the iommu_tbl_range_alloc().
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: David S. Miller <davem@davemloft.net> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 02fa305981f7e2934173604f22789918cdaa6e3b)
(cherry picked from commit ca2de477dfdcfa0a1f32f95a701e81467438d3f4) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Merge branch '4.1_sparc' of git://ca-git.us.oracle.com/linux-uek-apais into topic/uek-4.1/sparc
* '4.1_sparc' of git://ca-git.us.oracle.com/linux-uek-apais:
sparc64: vdso: simplify cpu_relax
vdso: replace current_thread_info when building vDSO rather than diking it out
sparc64, vdso: Add gettimeofday() and clock_gettime().
sparc64, vdso: sparc64 vDSO implementation.
When building the userspace parts of the vDSO code, we have to dike out things
from the various kernel headers we use that generate register relocations,
since we cannot handle relocations in the vDSO. The principal such thing is
current_thread_info(), which we used to dike out entirely -- but in the -rt
patchset, a lot of things in the headers reference this. So, instead,
simply have current_thread_info() generate nonsense code that doesn't emit
a relocation, so that its users still compile (though they would never
work -- but that's not important, since they are never used).
Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
(cherry picked from commit 4f9b3c6e7fe105ea04f89794007f97b43a63c897)
Nick Alcock [Mon, 8 Dec 2014 13:42:37 +0000 (13:42 +0000)]
sparc64, vdso: Add gettimeofday() and clock_gettime().
This commit adds gettimeofday() and clock_gettime() entry points to the SPARC64
vDSO: in conjunction with a suitably-modified glibc this provides a speedup to
gettimeofday(), time() and some clock_gettime() calls of on the order of
10--15x (the higher figure is for the coarse clock_gettime() clocks).
gettimeofday() and clock_gettime() use largely separate code paths: all
other approaches with less code duplication (e.g. doing all the work in
a struct timespec and only shifting it into a struct timeval before return)
turned out slower.
Tested on %stick-capable machines only: %tick codepaths untested.
Orabug: 20861959 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
(cherry picked from commit e8f9e5cfc9d297c7ebbc459b677ee0b8a3e45154)
Nick Alcock [Mon, 8 Dec 2014 13:32:19 +0000 (13:32 +0000)]
sparc64, vdso: sparc64 vDSO implementation.
This commit adds a vDSO similar to that used on x86: in this commit, that vDSO
is empty bar the ELF note used by glibc to verify that it knows about this vDSO.
The vDSO's location is somewhat randomized, so, as a consequence, tends to
randomize the locations of other shared libraries too. (The randomization
respects /proc/sys/kernel/randomize_va_space.)
It is derived from the implementation in recent kernels, in that it uses a C
generator to translate the vDSO shared library into C code and validate that it
contains no relocations and the like.
Notes for future improvement:
- There is no support for a vDSO in 32-bit userspace yet. This is just because
I want to get the sparc64 version working first: the compat vDSO
implementation adds significant complexity.
- The vDSO randomization process is ugly: we are calling get_unmapped_area()
twice, with a randomization in the middle. Eventually,
arch_get_unmapped_area() on SPARC64 should learn about PF_RANDOMIZE, as it
has on other arches.
Orabug: 20861959 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
(cherry picked from commit 2da875e6f5781dd196e9f055cd53a3ac0d80aaaa)
Merge branch '4.1_sparc' of git://ca-git.us.oracle.com/linux-uek-apais into topic/uek-4.1/sparc
* '4.1_sparc' of git://ca-git.us.oracle.com/linux-uek-apais: (25 commits)
lib/iommu-common.c: do not use 0xffffffffffffffffl for computing align_mask
sparc64: use ENTRY/ENDPROC in VISsave
SPARC64: PORT LDOMS TO UEK4
Fix incorrect ASI_ST_BLKINIT_MRU_S value
sparc64: perf: Use UREG_FP rather than UREG_I6
sparc64: perf: Add sanity checking on addresses in user stack
sparc64: Convert BUG_ON to warning
sparc: perf: Disable pagefaults while walking userspace stacks
sparc: time: Replace update_persistent_clock() with CONFIG_RTC_SYSTOHC
PCI: Set under_pref for mem64 resource of pcie device
sparc/PCI: Add mem64 resource parsing for root bus
PCI: Add pci_bus_addr_t
sparc64: Fix userspace FPU register corruptions.
sparc64: using 2048 as default for number of CPUS (cherry picked from commit 578ddb2512a5c908cd17ef8cbc43ff78dd399afd)
sparc64: iommu-common build error fix (cherry picked from commit accb4c6276793b991c6382bf57a58b40ea17eb11)
sparc64: fix Setup sysfs to mark LDOM sockets build error (cherry picked from commit 59be02427bfcac6c904ddd1374c35d63155b82d4)
sparc64: mmap fixed and shared
sparc64: restore TIF_FREEZE flag for sparc
sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly
sparc: Revert generic IOMMU allocator.
...
Sowmini Varadhan [Thu, 6 Aug 2015 22:46:39 +0000 (15:46 -0700)]
lib/iommu-common.c: do not use 0xffffffffffffffffl for computing align_mask
Using a 64 bit constant generates "warning: integer constant is too
large for 'long' type" on 32 bit platforms. Instead use ~0ul and
BITS_PER_LONG.
Detected by Andrew Morton on ARMD.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: David S. Miller <davem@davemloft.net> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 447f6a95a9c80da7faaec3e66e656eab8f262640) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 73958c651fbf70d8d8bf2a60b871af5f7a2e3199) Signed-off-by: Allen Pais <allen.pais@oracle.com>
David Ahern [Mon, 15 Jun 2015 20:15:45 +0000 (16:15 -0400)]
sparc64: perf: Add sanity checking on addresses in user stack
Processes are getting killed (sigbus or segv) while walking userspace
callchains when using perf. In some instances I have seen ufp = 0x7ff
which does not seem like a proper stack address.
This patch adds a function to run validity checks against the address
before attempting the copy_from_user. The checks are copied from the
x86 version as a start point with the addition of a 4-byte alignment
check.
David Ahern [Mon, 15 Jun 2015 20:15:44 +0000 (16:15 -0400)]
sparc64: Convert BUG_ON to warning
Pagefault handling has a BUG_ON path that panics the system. Convert it to
a warning instead. There is no need to bring down the system for this kind
of failure.
The following was hit while running:
perf sched record -g -- make -j 16
David Ahern [Mon, 15 Jun 2015 20:15:43 +0000 (16:15 -0400)]
sparc: perf: Disable pagefaults while walking userspace stacks
Page faults generated walking userspace stacks can call schedule to switch
out the task. When collecting callchains for scheduler tracepoints this
causes a deadlock as the tracepoints can be hit with the runqueue lock held:
[ 8138.159054] WARNING: CPU: 758 PID: 12488 at /opt/dahern/linux.git/arch/sparc/kernel/nmi.c:80 perfctr_irq+0x1f8/0x2b4()
[ 8138.203152] Watchdog detected hard LOCKUP on cpu 758
All the bridges 64-bit resource have pref bit, but the device resource does not
have pref set, then we can not find parent for the device resource,
as we can not put non-pref mem under pref mem.
According to pcie spec errta
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13, in some case it is ok to mark some as pref.
Only set pref for 64bit mmio when the entire path from the host to the adapter is
over PCI Express.
The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so
dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so
they don't fit in a dma_addr_t. d63e2e1f3df9 added new checking that
tripped over this mismatch.
Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
including both raw BAR values and DMA addresses. This will be 64 bits
on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then
dma_addr_t only needs to be wide enough to hold addresses from the DMA API.
If we have a series of events from userpsace, with %fprs=FPRS_FEF,
like follows:
ETRAP
ETRAP
VIS_ENTRY(fprs=0x4)
VIS_EXIT
RTRAP (kernel FPU restore with fpu_saved=0x4)
RTRAP
We will not restore the user registers that were clobbered by the FPU
using kernel code in the inner-most trap.
Traps allocate FPU save slots in the thread struct, and FPU using
sequences save the "dirty" FPU registers only.
This works at the initial trap level because all of the registers
get recorded into the top-level FPU save area, and we'll return
to userspace with the FPU disabled so that any FPU use by the user
will take an FPU disabled trap wherein we'll load the registers
back up properly.
But this is not how trap returns from kernel to kernel operate.
The simplest fix for this bug is to always save all FPU register state
for anything other than the top-most FPU save area.
Getting rid of the optimized inner-slot FPU saving code ends up
making VISEntryHalf degenerate into plain VISEntry.
Longer term we need to do something smarter to reinstate the partial
save optimizations. Perhaps the fundament error is having trap entry
and exit allocate FPU save slots and restore register state. Instead,
the VISEntry et al. calls should be doing that work.
This bug is about two decades old.
Reported-by: James Y Knight <jyknight@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b75513b0f1c734b1e084a6e9952ea6260d4724e3)
bob picco [Thu, 25 Jun 2015 00:10:18 +0000 (17:10 -0700)]
sparc64: mmap fixed and shared
Older sparc64 must have a VAC because there is concern that mmapping fixed
and shared with incorrect align would cause cache aliases. To my knowledge
this is not an issue for sun4v. I will eventually research this.
The patch appears required for uek4 too.
We will enforce the rigid alignment condition only for tlb_type != hypervisor.
sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly
The current sparc kernel has no representation for sockets though tools
like lscpu can pull this from sysfs. This patch walks the machine
description cache and socket hierarchy and marks sockets as well as cores
and threads such that a representative sysfs is created by
drivers/base/topology.c.
Before this patch:
$ lscpu
Architecture: sparc64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Big Endian
CPU(s): 1024
On-line CPU(s) list: 0-1023
Thread(s) per core: 8
Core(s) per socket: 1 <--- wrong
Socket(s): 128 <--- wrong
NUMA node(s): 4
NUMA node0 CPU(s): 0-255
NUMA node1 CPU(s): 256-511
NUMA node2 CPU(s): 512-767
NUMA node3 CPU(s): 768-1023
After this patch:
$ lscpu
Architecture: sparc64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Big Endian
CPU(s): 1024
On-line CPU(s) list: 0-1023
Thread(s) per core: 8
Core(s) per socket: 32
Socket(s): 4
NUMA node(s): 4
NUMA node0 CPU(s): 0-255
NUMA node1 CPU(s): 256-511
NUMA node2 CPU(s): 512-767
NUMA node3 CPU(s): 768-1023
Most of this patch was done by Chris with updates by David.
Signed-off-by: Chris Hyser <chris.hyser@oracle.com> Signed-off-by: David Ahern <david.ahern@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit acc455cffa75070d55e74fc7802b49edbc080e92)
Conflicts:
arch/sparc/include/asm/cpudata_64.h
arch/sparc/kernel/mdesc.c
arch/sparc/kernel/smp_64.c Signed-off-by: Allen Pais <allen.pais@oracle.com>
(cherry picked from commit bd1039234cf41d0afd35f8e9a302eac9c344d18d)
Allen Pais [Wed, 7 Jan 2015 12:36:22 +0000 (18:06 +0530)]
sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly.
The current sparc kernel has no representation for sockets (i.e. a 3rd level
cache shared by cores) though tools like lscpu can pull this from sysfs. This
patch walks the LDOM MD (machine description) cache hierarchy structure and
marks sockets as well as cores and threads such that a representative sysfs is
created by drivers/base/topology.c.
Allen Pais [Fri, 2 Jan 2015 05:47:00 +0000 (11:17 +0530)]
sparc64: prevent solaris control domain warnings about Domain Service handles
Solaris created its own protocol on top of domain service registration. This
matters because the control domain that linux is talking to is Solaris. The
hypervisor specs say that the handle used for service identification is simply
an opaque 64 bit number. The only constraint is that a handle never be used
twice (within a reasonable time frame) to prevent connection to a prior stale
registered handle. Solaris on the other hand reserves the bit 0x80000000 to
indicate what it calls client registration requests. These registration requests
are sent to the guest domain to prod it to send its own registration requests to
the control domain.
When a guest (linux in this case) sends its own registration requests with this
bit set, Solaris assumes that these come from clients running in the guest that
should not do this since there can only be one control domain. Linux not
knowing this uses the top 32 bits as a quick lookup index and sets the bottom 32
bits based off jiffies. Of course there are times when a handle is constructed
with the Solaris client bit not set and everything appears to work correctly
with no errors or warnings and times when the client bit is set and everything
works except the Solaris kernel puts a bunch of warnings into its dmesg buffer.
The fix is literally 1 character, changing the mask used to grab the bottom 32
bits of sched_clock() (jiffy based) to use only the bottom 31 bits. Halving the
roll-over time should not be an issue. Worse case additional jiffy bits can be
shifted into the upper 32 bits of the handle.
Domain service registration intermittently fails. Though using “reliable"
LDC communication, this only guarantees the data, not delivery. Analysis
indicated a timing issue that varies between boots. LDOM domain service
architecture is now sufficiently complicated that packets (domain service
registration requests in this case) do apparently get lost, the symptoms
being receiving neither an ACK or a NACK on the initial service registration
request.
This patch uses a timer and retries with delay up to N (currently 5) times
any requests that went unacknowledged, positively or negatively, before
reporting a failed registration attempt. Using timer with callback allows early
boot to progress as normal versus spinning in a loop. Also clean up of
./script/checkpatch.pl warnings and errors in ds.c.
Allen Pais [Fri, 2 Jan 2015 05:18:41 +0000 (10:48 +0530)]
sparc64: __init code no longer called during non __init
mdesc_update calling __init memory free code through a pointer at
non-init time. Since text page was already given back and reused
this results in an illegal instruction trap. Was not caught by
linker section mismatch checks due to pointer indirection.
This patch NULL's out mops pointer after __init time and then
checks for non-NULL before calling mops->free.
Signed-off-by: Chris Hyser <chris.hyser@oracle.com> Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com> Acked-by: Bob Picco <bob.picco@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
(cherry picked from commit 6dbae4a0137d7855472c4845b5db11cffa32efc1)
(cherry picked from commit f0673a413f04de21963ab7f3912eb9a84c52c66e)
Linus Torvalds [Sat, 20 Jun 2015 20:54:22 +0000 (13:54 -0700)]
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"A smattering of fixes,
mgag200:
don't accept modes that aren't aligned properly as hw can't do it
i915:
two regression fixes
radeon:
one query to allow userspace fixes
one oops fixer for older hw with new options enabled"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: don't probe MST on hw we don't support it on
drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING query
drm/mgag200: Reject non-character-cell-aligned mode widths
Revert "drm/i915: Don't skip request retirement if the active list is empty"
drm/i915: Always reset vma->ggtt_view.pages cache on unbinding
Linus Torvalds [Fri, 19 Jun 2015 17:34:14 +0000 (07:34 -1000)]
Merge tag 'sound-4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Nothing looks scary, just a few usual HD-audio regression fixes and
fixup, in addition to a minor Kconfig dependency fix for the old MIPS
drivers"
* tag 'sound-4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Fix unused label skip_i915
ALSA: hda - Fix noisy outputs on Dell XPS13 (2015 model)
ALSA: mips: let SND_SGI_O2 select SND_PCM
ALSA: hda - Fix audio crackles on Dell Latitude E7x40
ALSA: hda - adding a DAC/pin preference map for a HP Envy TS machine
Boris Brezillon [Fri, 27 Mar 2015 22:53:15 +0000 (23:53 +0100)]
clk: at91: pll: fix input range validity check
The PLL impose a certain input range to work correctly, but it appears that
this input range does not apply on the input clock (or parent clock) but
on the input clock after it has passed the PLL divisor.
Fix the implementation accordingly.
Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by: Jonas Andersson <jonas@microbit.se>
Linus Torvalds [Fri, 19 Jun 2015 03:02:27 +0000 (17:02 -1000)]
Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c documentation fix from Wolfram Sang:
"Here is a small documentation fix for I2C.
We already had a user who unsuccessfully tried to get the new slave
framework running with the currently broken example. So, before this
happens again, I'd like to have this how-to-use section fixed for 4.1
already. So that no more hacking time is wasted"
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: slave: fix the example how to instantiate from userspace
Dave Airlie [Fri, 19 Jun 2015 01:58:39 +0000 (11:58 +1000)]
Merge tag 'drm-intel-fixes-2015-06-18' of git://anongit.freedesktop.org/drm-intel into drm-fixes
one fix, one revert
* tag 'drm-intel-fixes-2015-06-18' of git://anongit.freedesktop.org/drm-intel:
Revert "drm/i915: Don't skip request retirement if the active list is empty"
drm/i915: Always reset vma->ggtt_view.pages cache on unbinding
Dave Airlie [Fri, 19 Jun 2015 01:55:29 +0000 (11:55 +1000)]
Merge branch 'drm-fixes-4.1' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes
two radeon fixes
one MST fix,
one query addition, destined for stable, and to fix a regression
* 'drm-fixes-4.1' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: don't probe MST on hw we don't support it on
drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING query
Linus Torvalds [Thu, 18 Jun 2015 06:56:57 +0000 (20:56 -1000)]
Merge tag 'trace-fix-filter-4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing filter fix from Steven Rostedt:
"Vince Weaver reported a warning when he added perf event filters into
his fuzzer tests. There's a missing check of balanced operations when
parenthesis are used, and this triggers a WARN_ON() and when reading
the failure, the filter reports no failure occurred.
The operands were not being checked if they match, this adds that"
* tag 'trace-fix-filter-4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Have filter check for balanced ops
Since when we start discussions about the usage Media Controller for
complex hardware, one thing become clear: the way it is, MC fails to
map anything different than capture/output/m2m video-only streaming.
The point is that MC has entities named as devnodes, but the only
devnode used (before the DVB patches) is MEDIA_ENT_T_DEVNODE_V4L.
Due to the way MC got implemented, however, this entity actually
doesn't represent the devnode, but the hardware I/O engine that
receives data via DMA.
By coincidence, such DMA is associated with the V4L device node
on webcam hardware, but this is not true even for other V4L2
devices. For example, on USB hardware, the DMA is done via the
USB controller. The data passes though a in-kernel filter that
strips off the URB headers. Other V4L2 devices like radio may not
even have DMA. When it have, the DMA is done via ALSA, and not
via the V4L devnode.
In other words, MC is broken as a whole, but tagging it as BROKEN
right now would do more harm than good.
So, instead, let's mark, for now, the DVB part as broken and
block all new changes to MC while we fix this mess, whith
we hopefully will do for the next Kernel version.
Hugh Dickins [Sun, 14 Jun 2015 16:48:09 +0000 (09:48 -0700)]
mm: shmem_zero_setup skip security check and lockdep conflict with XFS
It appears that, at some point last year, XFS made directory handling
changes which bring it into lockdep conflict with shmem_zero_setup():
it is surprising that mmap() can clone an inode while holding mmap_sem,
but that has been so for many years.
Since those few lockdep traces that I've seen all implicated selinux,
I'm hoping that we can use the __shmem_file_setup(,,,S_PRIVATE) which
v3.13's commit c7277090927a ("security: shmem: implement kernel private
shmem inodes") introduced to avoid LSM checks on kernel-internal inodes:
the mmap("/dev/zero") cloned inode is indeed a kernel-internal detail.
This also covers the !CONFIG_SHMEM use of ramfs to support /dev/zero
(and MAP_SHARED|MAP_ANONYMOUS). I thought there were also drivers
which cloned inode in mmap(), but if so, I cannot locate them now.
Wolfram Sang [Mon, 15 Jun 2015 17:51:46 +0000 (19:51 +0200)]
i2c: slave: fix the example how to instantiate from userspace
I copied the wrong shell code into the documentation. Sorry to all who
tried to get sense out of this current example :/ Slight rewording while
we are here.
Reported-by: Tim Bakker <bakkert@mymail.vcu.edu> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
Worse yet, reading the error message (the filter again) it says that
there was no error, when there clearly was. The issue is that the
code that checks the input does not check for balanced ops. That is,
having an op between a closed parenthesis and the next token.
This would only cause a warning, and fail out before doing any real
harm, but it should still not caues a warning, and the error reported
should work:
Takashi Iwai [Tue, 16 Jun 2015 10:23:36 +0000 (12:23 +0200)]
ALSA: hda - Fix unused label skip_i915
When CONFIG_SND_HDA_I915=n, we get a compile warning:
sound/pci/hda/hda_intel.c: In function ‘azx_probe_continue’:
sound/pci/hda/hda_intel.c:1882:2: warning: label ‘skip_i915’ defined but not used [-Wunused-label]
Fix it by putting again ifdef to it. Sigh.
Fixes: bf06848bdbe5 ('ALSA: hda - Continue probing even if i915 binding fails') Reported-by: Borislav Petkov <bp@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Steve Cornelius [Mon, 15 Jun 2015 23:52:59 +0000 (16:52 -0700)]
crypto: caam - fix RNG buffer cache alignment
The hwrng output buffers (2) are cast inside of a a struct (caam_rng_ctx)
allocated in one DMA-tagged region. While the kernel's heap allocator
should place the overall struct on a cacheline aligned boundary, the 2
buffers contained within may not necessarily align. Consenquently, the ends
of unaligned buffers may not fully flush, and if so, stale data will be left
behind, resulting in small repeating patterns.
This fix aligns the buffers inside the struct.
Note that not all of the data inside caam_rng_ctx necessarily needs to be
DMA-tagged, only the buffers themselves require this. However, a fix would
incur the expense of error-handling bloat in the case of allocation failure.
Cc: stable@vger.kernel.org Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com> Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Steve Cornelius [Mon, 15 Jun 2015 23:52:56 +0000 (16:52 -0700)]
crypto: caam - improve initalization for context state saves
Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final). Certain values in this state
block are loaded for processing using an inline-if, and when this
is done, the potential for uninitialized data can pose conflicts.
Therefore, this patch improves initialization of state data to
prevent false assignments using uninitialized data in the state block.
This patch addresses the following traceback, originating in
ahash_final_ctx(), although a problem like this could certainly
exhibit other symptoms:
Cc: stable@vger.kernel.org Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com> Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Radim Krčmář [Fri, 5 Jun 2015 18:57:41 +0000 (20:57 +0200)]
KVM: x86: fix lapic.timer_mode on restore
lapic.timer_mode was not properly initialized after migration, which
broke few useful things, like login, by making every sleep eternal.
Fix this by calling apic_update_lvtt in kvm_apic_post_state_restore.
There are other slowpaths that update lvtt, so this patch makes sure
something similar doesn't happen again by calling apic_update_lvtt
after every modification.
Cc: stable@vger.kernel.org Fixes: f30ebc312ca9 ("KVM: x86: optimize some accesses to LVTT and SPIV") Signed-off-by: Radim Krčmář <rkrcmar@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
The new Dell XPS13 also requires the similar quirk for fixing the
noisy outputs. (But, as the codec was changed, now the fixup for
Latitude is used instead.)
Fixes: 0aedb1626566 ("drm/i915: Don't skip request retirement if the active list is empty") Cc: stable@vger.kernel.org Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Takashi Iwai [Mon, 15 Jun 2015 09:59:32 +0000 (11:59 +0200)]
ALSA: hda - Fix audio crackles on Dell Latitude E7x40
We still got a report that the audio crackles and noises occur with
the recent 4.1 kernels on Dell machines. These machines seem to need
similar workarounds that have been applied to the recent Dell XPS 13
models. Since the codec of these machines (Dell Latitute E7240 and
E7440) is different from XPS 13's one, we need a new fixup entry.
Also, it was confirmed that the previous workaround to disable the
widget power-save (commit [219f47e4f964: ALSA: hda - Disable widget
power-saving for ALC292 & co]) is no longer needed after this fix.
So, this patch includes the partial revert of the commit, too.
Reported-and-tested-by: Mihai Donțu <mihai.dontu@gmail.com> Tested-by: Jonathan McDowell <noodles@earth.li> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Hui Wang [Mon, 15 Jun 2015 09:43:39 +0000 (17:43 +0800)]
ALSA: hda - adding a DAC/pin preference map for a HP Envy TS machine
On a HP Envy TouchSmart laptop, there are 2 speakers (main speaker
and subwoofer speaker), 1 headphone and 2 DACs, without this fixup,
the headphone will be assigned to a DAC and the 2 speakers will be
assigned to another DAC, this assignment makes the surround-2.1
channels invalid.
To fix it, here using a DAC/pin preference map to bind the main
speaker to 1 DAC and the subwoofer speaker will be assigned to another
DAC.
Cc: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Chris Wilson [Thu, 11 Jun 2015 07:06:08 +0000 (08:06 +0100)]
drm/i915: Always reset vma->ggtt_view.pages cache on unbinding
With the introduction of multiple views of an obj in the same vm, each
vma was taught to cache its copy of the pages (so that different views
could have different page arrangements). However, this missed decoupling
those vma->ggtt_view.pages when the vma released its reference on the
obj->pages. As we don't always free the vma, this leads to a possible
scenario (e.g. execbuffer interrupted by the shrinker) where the vma
points to a stale obj->pages, and explodes.
drm/i915: Infrastructure for supporting different GGTT views per object
Tvrtko says, if someone else will be confused how this can happen, key
is the reservation execbuffer path. That puts the VMA on the exec_list
which prevents i915_vma_unbind and i915_gem_vma_destroy from fully
destroying the VMA. So the VMA is left existing as an empty object in
the list - unbound and disassociated with the backing store. Kind of a
cached memory object. And then re-using it needs to clear the cached
pages pointer which is fixed above.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1227892 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michel Thierry <michel.thierry@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
[Jani: Added Tvrtko's explanation to commit message.] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Linus Torvalds [Mon, 15 Jun 2015 01:38:57 +0000 (15:38 -1000)]
Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus
Pull more MIPS fixes from Ralf Baechle:
"Another round of 4.1 MIPS fixes, one fix to a MIPS-specific #if
condition in lib/mpi, one fix to the MIPS GIC irqchip driver and one
SSB fix.
Details:
- fix handling of clock in chipco SSB driver.
- fix two MIPS-specific #if conditions to correctly work for GCC 5.1.
- fix damage to R6 pgtable bits done by XPA support.
- fix possible crash due to unloading modules that contain statically
defined platform devices.
- fix disabling of the MSA ASE on context switch to also work
correctly when a new thread/process has the CPU for the very first
time.
This is part of linux-next and has been beaten to death on
Imagination's test farm.
While things are not looking too grim this pull request also means the
rate of fixes for 4.1 remains nearly constant so I'd not be unhappy if
you'd delay the release"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MPI: MIPS: Fix compilation error with GCC 5.1
IRQCHIP: mips-gic: Don't nest calls to do_IRQ()
MIPS: MSA: bugfix - disable MSA correctly for new threads/processes.
MIPS: Loongson: Do not register 8250 platform device from module.
MIPS: Cobalt: Do not build MTD platform device registration code as module.
SSB: Fix handling of ssb_pmu_get_alp_clock()
MIPS: pgtable-bits: Fix XPA damage to R6 definitions.
projects / users / jedix / linux-maple.git / log