Both are unused since lmo commit fdffbafbb38723618626c70ffdc6ff9175cdffa2
[Lots of FPU bug fixes from Kjeld Borch Egevang.]
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
LONG_LONG_MAX is a symbol defined in <limits.h> which may not be available
so better rely on something provided by a kernel header. While at it,
turn these function-like macros into inline functions.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Most of these tests should be runtime tests. This also finally means
that on a MIPS III systems MIPS IV opcodes are going to result in an
exception as they're supposed to.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The header file had no include guards; this only happened to work because
the file only contains macro definitions and protypes.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Unfortunately this update became bigger than previous pull requests,
which is almost a pattern in rc5-6. But, the only obvious big changes
are for the new Intel DSP ASoC drivers, so the impact must be fairly
limited.
Other than that, usual small fixes in various fields: HD-audio, ASoC
core and ASoC fsl and codec drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTdPwHAAoJEGwxgFQ9KSmk2MoQAI91MJeGAS3nZczw+TnHHBg7
tk/0r85Kdwem2M9tywZVM78q7vECpB7UV8nZXAIHKcc1fpEjzHu3WJnR5zyqrEDO
4o+9gx9gdwUa7Tv+L8n0A7xSAdIPCrqEL5/776YuUUR/MqJsjemP5bbudzd4ffL7
asLEcJWf0HMHePEajyuay21OWtCRABLLGjgVd0QOFce2B8yBmUswHy0XPYV6+39A
j+G7/gNK1MMF+gmPMy5XV89C+5V1V9wZ68cJuBKJKODJ6SDnRZGaRt84W/lL15Ag
NtzFIT9Sd/qwiOwTtx6qNGmoyxrDfpNQ1Beqd1Mr9kJTowOziRqbZSyNYkKJKkHy
FvRuZkRyDPlmsYnBCxQqaKFhMcWu0n6urssU6y2rCWi0HrBsB4i/ttSfFRHwdASt
jGj/YU2bCc3B2SeZy+xlKW++KsPS829F4cFGD/kx7PsegGetmAp1S1jJJGXPIno4
jHnVKISWUGGxrPkL+6QxOBFPqtErx0/k/Scb8PwlugkAqQnN2w8Ds5vQ02cs/gOC
kPdo5c4mnWLLF7YEwdyd2+u2dlqGoIIAJM0i4qiNRPccAjxrfd6Ao78BoGzvktjg
nmzKsHJO/GF3BTf2o73Evr1jtdxmU+9gL8DKsYgFyBOrr511ieetswgIWbZBej+0
UDDaGufcAX9qDoLktzsC
=h7mJ
-----END PGP SIGNATURE-----
Merge tag 'sound-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Unfortunately this update became bigger than previous pull requests,
which is almost a pattern in rc5-6. But, the only obvious big changes
are for the new Intel DSP ASoC drivers, so the impact must be fairly
limited.
Other than that, usual small fixes in various fields: HD-audio, ASoC
core and ASoC fsl and codec drivers"
* tag 'sound-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (26 commits)
ALSA: sb_mixer: missing return statement
ASoC: wm8962: Update register CLASS_D_CONTROL_1 to be non-volatile
ASoC: Intel: Fix Baytrail SST DSP firmware loading
ALSA: hda - mask buggy stream DMA0 for Broadwell display controller
ALSA: hda - Add new GPU codec ID to snd-hda
ASoC: fsl_esai: Set PCRC and PRRC registers at the end of hw_params()
ASoC: fsl_esai: Only bypass sck_div for EXTAL source
ASoC: fsl_esai: Fix incorrect condition within ratio range check for FP
ASoC: dapm: Fix SUSPEND -> OFF bias sequence
ASoC: dapm: Skip CODEC<->CODEC links in connect_dai_link_widgets()
ASoC: pcm: Fix incorrect condition check for case SNDRV_PCM_TRIGGER_SUSPEND
ALSA: hda - add headset mic detect quirks for three Dell laptops
ASoC: Update Cirrus Logic CODEC maintainers.
ASoC: Intel: Fix block offset calculations.
ASoC: Intel: Fix check for pdata usage before dereference.
ASoC: Intel: Fix stream position pointer.
ASoC: Intel: Fix allow hw_params to be called more than once.
ASoC: Intel: Fix Audio DSP usage when IOMMU is enabled.
ASoC: Intel: Fix Haswell/Broadwell DSP page table creation.
ASoC: Intel: Fix allocated block list usage when adding blocks.
...
Pull MIPS fixes from Ralf Baechle:
"MIPS fixes for various loose ends:
- Fix workarounds for R4000 erratum.
- Patch up DEC, Siemens-Nixdorf and Loongson hardware support.
- Wire up renameat2 syscall.
- Delete unused file - it was causing false warnings from maintenance
scripts.
- Revert a patch because it's functionality is now implemented twice
which causes superfluous /proc/cpuinfo output.
- Fix a microMIPS regression"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: mm: Fix broken microMIPS kernel regression.
MIPS: Add new AUDIT_ARCH token for the N32 ABI on MIPS64
MIPS: Wire up renameat2 syscall.
MIPS: inst.h: Rename BITFIELD_FIELD to __BITFIELD_FIELD.
MIPS: Remove file missed when removing rm9k support a while ago.
MIPS/loongson2_cpufreq: Fix CPU clock rate setting
MIPS: Loongson: No need to select GENERIC_HARDIRQS_NO__DO_IRQ
MIPS: csum_partial.S CPU_DADDI_WORKAROUNDS bug fix
MIPS: __strncpy_from_user_asm CPU_DADDI_WORKAROUNDS bug fix
MIPS: __delay CPU_DADDI_WORKAROUNDS bug fix
MIPS: DEC/SNI: O32 wrapper stack switching fixes
MIPS: DEC: Bus error handler <asm/cpu-type.h> fixes
MAINTAINERS: TURBOchannel: Update entry
Revert "MIPS: MT: proc: Add support for printing VPE and TC ids"
Pull parisc fixes from Helge Deller:
"There are two patches in here:
The first patch greatly improves latency and corrects the memory
ordering in our light-weight atomic locking syscall.
The second patch ratelimits printing of userspace segfaults in the
same way as it's done on other platforms. This fixes a possible DOS
on parisc since it prevents the syslog to grow too fast. For example,
when the debian acl2 package was built on our debian buildd servers,
this package produced lots of gigabytes in syslog in very short time
and thus filled our harddisks, which then turned the server nearly
completely unaccessible and unresponsive"
* 'parisc-3.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Improve LWS-CAS performance
parisc: ratelimit userspace segfault printing
Support forced affinity setting)
- fix arm64 pud_huge() to return 0 when only 2 levels page tables are
used (__PAGETABLE_PMD_FOLDED defined and pmd_huge already covers block
entries at the first level), otherwise KVM gets confused
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAABAgAGBQJTdkdgAAoJEGvWsS0AyF7x1iYQALKLvpQm8wWndDyDx3AoFagp
tXdoNCUJhOeoc2VlipwbrHQ0M7ZfHzVS21TceDbC6COmjkItmthPnt0ImpA29831
wtm34+lNH/Bim1GLEhwR2EcEVLpBH8/gDdwy5lE7olupO63ViYUUTZtaacrg5SgD
zlVdo+kp+MzmDoz3FkUrlPkFstbm7GcWe2BYEpOu828Qd4uKHtjd13Ud9MgdJRJi
9TeBh68MjALK3KWhd0HOt0ESJjb5pY6whMv/8stg/cD/o6zrqUapxNNk9tqE0PIy
crOzOatmuvm8PJrkgJPV8Xnk9tToz+/j/djiFD4imaHAodQKk6eSPD0wwx+NTlPs
q7fPAlhYNgpvExXrbF0mqtb8q3er6MRnFp6OHWgwU6a+O8tt4Rkms/s9XuuAM/us
iX3t/oEjHXGe7uhIEQdrnWdVVHAJpz6HCbDQ9GgsZPZAS6D4NSIqSf35f4KjoYsH
FFoNrEqtoJz06wxaI9M9lAzUuQQO3vYUDdi3Xk+SHBjumztRcEh432niOoITZEL8
ickfQa2BHqqQwq9nK1i9SEbH7n1tTKaJAOAtK8c8Rnjzh0ckkODvZbhUsyUuF66Y
+jWgXh2NVTUN/tXMn8tQFYbxNRQR+z6J+kxOyG62knaAjjeUokdVAhRhn+lvcE/F
wFIU9cQOkLCWIAzsW/WS
=Ql27
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull two arm64 fixes from Catalin Marinas:
- arm64 migrate_irqs() fix following commit ffde1de640 (irqchip: Gic:
Support forced affinity setting)
- fix arm64 pud_huge() to return 0 when only 2 levels page tables are
used (__PAGETABLE_PMD_FOLDED defined and pmd_huge already covers
block entries at the first level), otherwise KVM gets confused
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: fix pud_huge() for 2-level pagetables
arm64: use cpu_online_mask when using forced irq_set_affinity
Mostly fixes for metag and parisc relating to upgrowing stacks.
* Fix missing compiler barriers in metag memory barriers.
* Fix BUG_ON on metag when RLIMIT_STACK hard limit is increased beyond
safe value.
* Make maximum stack size configurable. This reduces the default user
stack size back to 80MB (especially on parisc after their removal of
_STK_LIM_MAX override). This only affects metag and parisc.
* Remove metag _STK_LIM_MAX override to match other arches and follow
parisc, now that it is safe to do so (due to the BUG_ON fix mentioned
above).
* Finally now that both metag and parisc _STK_LIM_MAX overrides have
been removed, it makes sense to remove _STK_LIM_MAX altogether.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTdAc3AAoJEGwLaZPeOHZ6L2QP/ihJag44CyWKKpeu/5FUkjP6
62wX4cYKCFR9pTkOZDViWs7c+xrmW6OtORfQKuXu1g68L3v2cwb0HmcvybQ75pIQ
CbaN+d5OnGPjHGYCSVqQBKlJ0qbcgQfoNUuCVOZx9kZgnCYQhJlh4HYRwHdUv9WY
1FA3wor/JTTAiKvPBv+/t4NzTpTafpSIhYLahjxZbtuU1WjEfmj8QgWQpzTEJSeZ
AyNE/nDlcYcdq4lDxMz2pcQfmJ2MpE56wvXJ7IdXadLaLp4yzc+WTAvFzNJ1XnAN
2IcyNBpgF/vMXCbErA9QQegYwKd9jpF0w3oQmNLkgr27Kv27iL2sLIEWVn3FAXCu
p+I0ypMlkD/gSdofCUaWTiGGOQiKMqAWJMfjky8RjA7Qz5TdLCldpjjuZEMKl8hM
SLjkmgZHMG2/rJ8MosOL+ARAXl88v25gfM6rNIPTtMzH72qevrHgjFPj6pWHejhE
0E43yDS+zt215HrFCXYBhVbFY1NM7JeBS8NFd9Y/8LKTWc8QSi2h8Q1ZaobKJi4O
0zlKxRRR4QmmtF7S5wL/qOQ0U95HBvYSx+Ssp3C0eh/PEkZYWm0jiXtaKBCYtnDx
33wRutv+R9sSkKaiiURBh9/VPWFLQ1ak5z+ejqrv32+oBzt/zmxb7LgwsxdAbAms
9r/8XaY3V+JBPw7UxfQN
=aveq
-----END PGP SIGNATURE-----
Merge tag 'metag-for-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag
Pull Metag architecture and related fixes from James Hogan:
"Mostly fixes for metag and parisc relating to upgrowing stacks.
- Fix missing compiler barriers in metag memory barriers.
- Fix BUG_ON on metag when RLIMIT_STACK hard limit is increased
beyond safe value.
- Make maximum stack size configurable. This reduces the default
user stack size back to 80MB (especially on parisc after their
removal of _STK_LIM_MAX override). This only affects metag and
parisc.
- Remove metag _STK_LIM_MAX override to match other arches and follow
parisc, now that it is safe to do so (due to the BUG_ON fix
mentioned above).
- Finally now that both metag and parisc _STK_LIM_MAX overrides have
been removed, it makes sense to remove _STK_LIM_MAX altogether"
* tag 'metag-for-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag:
asm-generic: remove _STK_LIM_MAX
metag: Remove _STK_LIM_MAX override
parisc,metag: Do not hardcode maximum userspace stack size
metag: Reduce maximum stack size to 256MB
metag: fix memory barriers
Pull drm/intel fixes from Dave Airlie:
"Just some intel fixes.
I have some radeon ones but I need to get some patches dropped from
the pull req"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: Increase WM memory latency values on SNB
drm/i915: restore backlight precision when converting from ACPI
drm/i915: Use the first mode if there is no preferred mode in the EDID
drm/i915/dp: force eDP lane count to max available lanes on BDW
drm/i915/vlv: reset VLV media force wake request register
drm/i915/SDVO: For sysfs link put directory and target in correct order
drm/i915: use lane count and link rate from VBT as minimums for eDP
drm/i915: clean up VBT eDP link param decoding
drm/i915: consider the source max DP lane count too
Pull x86 fixes from Peter Anvin.
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86-64, modify_ldt: Make support for 16-bit segments a runtime option
x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()
x86, rdrand: When nordrand is specified, disable RDSEED as well
Pull timer fix from Thomas Gleixner:
"A single bug fix for a long standing issue:
- Updating the expiry value of a relative timer _after_ letting the
idle logic select a target cpu for the timer based on its stale
expiry value is outright stupid. Thanks to Viresh for spotting the
brainfart"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
hrtimer: Set expiry time before switch_hrtimer_base()
Pull irq fixes from Thomas Gleixner:
"Two small updates from the irq departement:
- Provide missing inline stub for a SMP only function
- Add sub-maintainer for the drivers/irqchip/ part of the irq
subsystem. YAY!"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
MAINTAINERS: Add co-maintainer for drivers/irqchip
genirq: Provide irq_force_affinity fallback for non-SMP
Intel fixes for regressions, black screens and hangs, for 3.15.
* tag 'drm-intel-fixes-2014-05-16' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Increase WM memory latency values on SNB
drm/i915: restore backlight precision when converting from ACPI
drm/i915: Use the first mode if there is no preferred mode in the EDID
drm/i915/dp: force eDP lane count to max available lanes on BDW
drm/i915/vlv: reset VLV media force wake request register
drm/i915/SDVO: For sysfs link put directory and target in correct order
drm/i915: use lane count and link rate from VBT as minimums for eDP
drm/i915: clean up VBT eDP link param decoding
drm/i915: consider the source max DP lane count too
The following happens when trying to run a kvm guest on a kernel
configured for 64k pages. This doesn't happen with 4k pages:
BUG: failure at include/linux/mm.h:297/put_page_testzero()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF 3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1
Call trace:
[<fffffe0000096034>] dump_backtrace+0x0/0x16c
[<fffffe00000961b4>] show_stack+0x14/0x1c
[<fffffe000066e648>] dump_stack+0x84/0xb0
[<fffffe0000668678>] panic+0xf4/0x220
[<fffffe000018ec78>] free_reserved_area+0x0/0x110
[<fffffe000018edd8>] free_pages+0x50/0x88
[<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40
[<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44
[<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184
[<fffffe00000a1938>] kvm_vm_release+0x10/0x1c
[<fffffe00001edc1c>] __fput+0xb0/0x288
[<fffffe00001ede4c>] ____fput+0xc/0x14
[<fffffe00000d5a2c>] task_work_run+0xa8/0x11c
[<fffffe0000095c14>] do_notify_resume+0x54/0x58
In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page()
on the stage2 pgd which leads to the BUG in put_page_testzero(). This
happens because a pud_huge() test in unmap_range() returns true when it
should always be false with 2-level pages tables used by 64k pages.
This patch removes support for huge puds if 2-level pagetables are
being used.
Signed-off-by: Mark Salter <msalter@redhat.com>
[catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: <stable@vger.kernel.org> # v3.11+
The attached change significantly improves the performance of the LWS-CAS code
in syscall.S.
This allows a number of packages to build (e.g., zeromq3, gtest and libxs)
that previously failed because slow LWS-CAS performance under contention. In
particular, interrupts taken while the lock was taken degraded performance
significantly.
The change does the following:
1) Disables interrupts around the CAS operation, and
2) Changes the loads and stores to use the ordered completer, "o", on
PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is
accepted on both PA 1.X and 2.0.
The use of ordered loads and stores probably makes no difference on all
existing hardware, but it seemed pedantically correct. In particular, the CAS
operation must complete before LDCW lock is released. As written before, a
processor could reorder the operations.
I don't believe the period interrupts are disabled is long enough to
significantly increase interrupt latency. For example, the TLB insert code is
longer. Worst case is a memory fault in the CAS operation.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # 3.13+
Signed-off-by: Helge Deller <deller@gmx.de>
Ratelimit printing of userspace segfaults and make it runtime
configurable via the /proc/sys/debug/exception-trace variable. This
should resolve syslog from growing way too fast and thus prevents
possible system service attacks.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 3.13+
On SNB the BIOS provided WM memory latency values seem insufficient to
handle high resolution displays.
In this particular case the display mode was a 2560x1440@60Hz, which
makes the pixel clock 241.5 MHz. It was empirically found that a memory
latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
is what the typical BIOS provided values are on IVB systems.
Increase the WM memory latency values to at least 1.2 usec on SNB.
Hopefully this won't have a significant effect on power consumption.
v2: Increase the latency values regardless of the pixel clock
Cc: Robert N <crshman@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254
Tested-by: Robert Navarro <crshman@gmail.com>
Tested-by: Vitaly Minko <vitaly.minko@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When we set backlight on behalf of ACPI opregion, we will convert the
backlight value in the 0-255 range defined in opregion to the actual
hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow
when doing scale) is meant to fix the overflow problem when doing the
conversion, but it also caused a problem that the converted hardware
level doesn't quite represent the intended value: say user wants maximum
backlight level(255 in opregion's range), then we will calculate the
actual hardware level to be: level = freq / max * level, where freq is
the hardware's max backlight level(937 on an user's box), and max and
level are all 255. The converted value should be 937 but the above
calculation will yield 765.
To fix this issue, just use 64 bits to do the calculation to keep the
precision and avoid overflow at the same time.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491
Reported-by: Nico Schottelius <nico-bugzilla.kernel.org@schottelius.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This matches the algorithm used by earlier kernels when selecting the
mode for the fbcon. And only if there is no modes at all, do we fall
back to using the BIOS configuration. Seamless transition is still
preserved (from the BIOS configuration to ours) so long as the BIOS has
also chosen what we hope is the native configuration.
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[Jani: applied Chris' "Please imagine that I wrote this correctly."]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
There are certain BDW high res eDP machines that regressed due to
commit 38aecea0cc
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Mar 3 11:18:10 2014 +0100
drm/i915: reverse dp link param selection, prefer fast over wide again
The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at
2.7 Gbps on the affected machines. Link training succeeded for both, but
the screen remained blank with the former config. Further investigation
showed that 4 lanes at 5.4 Gbps worked also.
The root cause for the blank screen using 2 lanes remains unknown, but
apparently the driver for a certain other operating system by default
uses the max available lanes. Follow suit on Broadwell eDP, for at least
until we figure out what is going on.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Checkin:
b3b42ac2cb x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
disabled 16-bit segments on 64-bit kernels due to an information
leak. However, it does seem that people are genuinely using Wine to
run old 16-bit Windows programs on Linux.
A proper fix for this ("espfix64") is coming in the upcoming merge
window, but as a temporary fix, create a sysctl to allow the
administrator to re-enable support for 16-bit segments.
It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
you hit this issue and care about your old Windows program more than
you care about a kernel stack address information leak, you can do
echo 1 > /proc/sys/abi/ldt16
as root (add it to your startup scripts), and you should be ok.
The sysctl table is only added if you have COMPAT support enabled on
x86-64, but I assume anybody who runs old windows binaries very much
does that ;)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com
Cc: <stable@vger.kernel.org>
_STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from
an arch's include/uapi/asm-generic/resource.h file, but is no longer
used since both parisc and metag removed the override. Therefore remove
it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY
directly in include/asm-generic/resource.h.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org
Cc: Helge Deller <deller@gmx.de>
Cc: John David Anglin <dave.anglin@bell.net>
Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to
256MB, apparently in an attempt to prevent setup_arg_pages's
STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is
far too large for Meta's limited virtual address space and hits a BUG_ON
(stack_top is usually 0x3ffff000).
However the commit "metag: Reduce maximum stack size to 256MB" reduces
the absolute stack size limit to a safe value for metag. This allows the
default _STK_LIM_MAX override to be removed, bringing the default
behaviour in line with all other architectures. Parisc in particular
recently removed their override of _STK_LIMT_MAX in commit e0d8898d76
(parisc: remove _STK_LIM_MAX override) since it subtly affects stack
allocation semantics in userland. Meta's uapi/asm/resource.h can now be
removed and switch to using generic-y.
Suggested-by: Helge Deller <deller@gmx.de>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>
This patch affects only architectures where the stack grows upwards
(currently parisc and metag only). On those do not hardcode the maximum
initial stack size to 1GB for 32-bit processes, but make it configurable
via a config option.
The main problem with the hardcoded stack size is, that we have two
memory regions which grow upwards: stack and heap. To keep most of the
memory available for heap in a flexmap memory layout, it makes no sense
to hard allocate up to 1GB of the memory for stack which can't be used
as heap then.
This patch makes the stack size for 32-bit processes configurable and
uses 80MB as default value which has been in use during the last few
years on parisc and which hasn't showed any problems yet.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>
