Using sendfile with below small program to get MD5 sums of some files,
it appear that big files (over 64kbytes with 4k pages system) get a
wrong MD5 sum while small files get the correct sum.
This program uses sendfile() to send a file to an AF_ALG socket
for hashing.
After investivation, it appears that sendfile() sends the files by blocks
of 64kbytes (16 times PAGE_SIZE). The problem is that at the end of each
block, the SPLICE_F_MORE flag is missing, therefore the hashing operation
is reset as if it was the end of the file.
This patch adds SPLICE_F_MORE to the flags when more data is pending.
Doug Anderson [Fri, 1 May 2015 16:01:27 +0000 (09:01 -0700)]
pinctrl: Don't just pretend to protect pinctrl_maps, do it for real
Way back, when the world was a simpler place and there was no war, no
evil, and no kernel bugs, there was just a single pinctrl lock. That
was how the world was when (57291ce pinctrl: core device tree mapping
table parsing support) was written. In that case, there were
instances where the pinctrl mutex was already held when
pinctrl_register_map() was called, hence a "locked" parameter was
passed to the function to indicate that the mutex was already locked
(so we shouldn't lock it again).
A few years ago in (42fed7b pinctrl: move subsystem mutex to
pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex.
...but (oops) we forgot to re-think about the whole "locked" parameter
for pinctrl_register_map(). Basically the "locked" parameter appears
to still refer to whether the bigger pinctrl_dev mutex is locked, but
we're using it to skip locks of our (now separate) pinctrl_maps_mutex.
That's kind of a bad thing(TM). Probably nobody noticed because most
of the calls to pinctrl_register_map happen at boot time and we've got
synchronous device probing. ...and even cases where we're
asynchronous don't end up actually hitting the race too often. ...but
after banging my head against the wall for a bug that reproduced 1 out
of 1000 reboots and lots of looking through kgdb, I finally noticed
this.
Anyway, we can now safely remove the "locked" parameter and go back to
a war-free, evil-free, and kernel-bug-free world.
Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by: Doug Anderson <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
xen: Add __GFP_DMA flag when xen_swiotlb_init gets free pages on ARM
Make sure that xen_swiotlb_init allocates buffers that are DMA capable
when at least one memblock is available below 4G. Otherwise we assume
that all devices on the SoC can cope with >4G addresses. We do this on
ARM and ARM64, where dom0 is mapped 1:1, so pfn == mfn in this case.
Tony Lindgren [Thu, 23 Apr 2015 23:54:17 +0000 (16:54 -0700)]
gpio: omap: Fix regression for MPUIO interrupts
At some point with all the GPIO clean-up we've broken the
MPUIO interrupts. Those are just a little bit different from
the GPIO interrupts, so we can fix it up just by setting
different irqchip functions for it. And then we can just
remove all old code trying to do the same.
Chuanxiao Dong [Tue, 12 Aug 2014 04:01:30 +0000 (12:01 +0800)]
mmc: card: Don't access RPMB partitions for normal read/write
During kernel boot, it will try to read some logical sectors
of each block device node for the possible partition table.
But since RPMB partition is special and can not be accessed
by normal eMMC read / write CMDs, it will cause below error
messages during kernel boot:
...
mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00
mmcblk0rpmb: retrying using single block read
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
end_request: I/O error, dev mmcblk0rpmb, sector 0
Buffer I/O error on device mmcblk0rpmb, logical block 0
end_request: I/O error, dev mmcblk0rpmb, sector 8
Buffer I/O error on device mmcblk0rpmb, logical block 1
end_request: I/O error, dev mmcblk0rpmb, sector 16
Buffer I/O error on device mmcblk0rpmb, logical block 2
end_request: I/O error, dev mmcblk0rpmb, sector 24
Buffer I/O error on device mmcblk0rpmb, logical block 3
...
This patch will discard the access request in eMMC queue if
it is RPMB partition access request. By this way, it avoids
trigger above error messages.
mmc: sh_mmcif: Fix timeout value for command request
f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout")
changed the timeout value from 1000 jiffies to 1s. In the case where
HZ is 1000 the values are the same. However, for smaller HZ values the
timeout is now smaller, 1s instead of 10s in the case of HZ=100.
Since the timeout occurs in spite of a normal data transfer a timeout of
10s seems more appropriate. This restores the previous timeout in the
case where HZ=100 and results in an increase over the previous timeout
for larger values of HZ.
Fixes: f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") Signed-off-by: Takeshi Kihara <[email protected]>
[horms: rewrote changelog to refer to HZ] Signed-off-by: Simon Horman <[email protected]> Signed-off-by: Yoshihiro Kaneko <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
Bobby Powers [Mon, 27 Apr 2015 15:10:41 +0000 (08:10 -0700)]
x86/fpu: Always restore_xinit_state() when use_eager_cpu()
The following commit:
f893959b0898 ("x86/fpu: Don't abuse drop_init_fpu() in flush_thread()")
removed drop_init_fpu() usage from flush_thread(). This seems to break
things for me - the Go 1.4 test suite fails all over the place with
floating point comparision errors (offending commit found through
bisection).
The functional change was that flush_thread() after this commit
only calls restore_init_xstate() when both use_eager_fpu() and
!used_math() are true. drop_init_fpu() (now fpu_reset_state()) calls
restore_init_xstate() regardless of whether current used_math() - apply
the same logic here.
Switch used_math() -> tsk_used_math(tsk) to consistently use the grabbed
tsk instead of current, like in the rest of flush_thread().
Jani Nikula [Tue, 5 May 2015 13:32:12 +0000 (16:32 +0300)]
drm/i915/dp: there is no audio on port A
The eDP port A register on PCH split platforms has a slightly different
register layout from the other ports, with bit 6 being either alternate
scrambler reset or reserved, depending on the generation. Our
misinterpretation of the bit as audio has lead to warning.
Fix this by not enabling audio on port A, since none of our platforms
support audio on port A anyway.
v2: DDI doesn't have audio on port A either (Sivakumar Thulasimani)
H.J. Lu [Thu, 18 Dec 2014 02:05:29 +0000 (18:05 -0800)]
x86/asm: Use -mskip-rax-setup if supported
GCC 5 added a compiler option, -mskip-rax-setup, for x86-64. It skips
setting up the RAX register when SSE is disabled and there are no
variable arguments passed in vector registers. (According to the x86_64
ABI, %al is used as a hidden register containing the number of vector
registers used).
Since the kernel doesn't pass vector registers to functions with
variable arguments, this option can be used to optimize the x86-64
kernel.
This GCC feature was suggested by Rasmus Villemoes <[email protected]>.
This is the corresponding kernel change using it.
Linus Torvalds [Wed, 6 May 2015 02:42:01 +0000 (19:42 -0700)]
Merge tag 'for-linus-4.1-1' of git://git.code.sf.net/p/openipmi/linux-ipmi
Pull IPMI fixes from Corey Minyard:
"Lots of minor IPMI fixes, especially ones that have have come up since
the SSIF driver has been in the main kernel for a while"
* tag 'for-linus-4.1-1' of git://git.code.sf.net/p/openipmi/linux-ipmi:
ipmi: Fix multi-part message handling
ipmi: Add alert handling to SSIF
ipmi: Fix a problem that messages are not issued in run_to_completion mode
ipmi: Report an error if ACPI _IFT doesn't exist
ipmi: Remove unused including <linux/version.h>
ipmi: Don't report err in the SI driver for SSIF devices
ipmi: Remove incorrect use of seq_has_overflowed
ipmi:ssif: Ignore spaces when comparing I2C adapter names
ipmi_ssif: Fix the logic on user-supplied addresses
Linus Torvalds [Wed, 6 May 2015 01:52:13 +0000 (18:52 -0700)]
Merge branch 'akpm' (patches from Andrew)
Merge misc fixes from Andrew Morton:
"16 patches
This includes a new rtc driver for the Abracon AB x80x and isn't very
appropriate for -rc2. It was still being fiddled with a bit during
the merge window and I fell asleep during -rc1"
[ So I took the new driver, it seems small and won't regress anything.
I'm a softy. - Linus ]
* emailed patches from Andrew Morton <[email protected]>:
rtc: armada38x: fix concurrency access in armada38x_rtc_set_time
ocfs2: dlm: fix race between purge and get lock resource
nilfs2: fix sanity check of btree level in nilfs_btree_root_broken()
util_macros.h: have array pointer point to array of constants
configfs: init configfs module earlier at boot time
mm/hwpoison-inject: check PageLRU of hpage
mm/hwpoison-inject: fix refcounting in no-injection case
mm: soft-offline: fix num_poisoned_pages counting on concurrent events
rtc: add rtc-abx80x, a driver for the Abracon AB x80x i2c rtc
Documentation: bindings: add abracon,abx80x
kasan: show gcc version requirements in Kconfig and Documentation
mm/memory-failure: call shake_page() when error hits thp tail page
lib: delete lib/find_last_bit.c
MAINTAINERS: add co-maintainer for LED subsystem
zram: add Designated Reviewer for zram in MAINTAINERS
revert "zram: move compact_store() to sysfs functions area"
Linus Torvalds [Wed, 6 May 2015 01:14:04 +0000 (18:14 -0700)]
Merge tag 'platform-drivers-x86-v4.1-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
Pull x86 platform driver fixes from Darren Hart:
"This includes a trivial warning and adding a Lenovo laptop to an
existing quirk.
I've held off on things like the latter in the past, but I didn't feel
it was risky enough to push out to 4.2.
- thinkpad_acpi:
Fix warning for static not at beginning
- ideapad_laptop:
Add Lenovo G40-30 to devices without radio switch"
* tag 'platform-drivers-x86-v4.1-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
thinkpad_acpi: Fix warning for static not at beginning
ideapad_laptop: Add Lenovo G40-30 to devices without radio switch
The values was not being re-initialized, if something went wrong
handling a multi-part message and it got left in a bad state, it
might be an issue.
The commands were not correct when issuing multi-part reads, the
code was not passing in the proper value for commands. Also clean
up some minor formatting issues.
Get the block number from the right location, limit the maximum send
message size to 63 bytes and explain why, and fix some minor sylistic
issues.
The SSIF interface can optionally have an SMBus alert come in when
data is ready. Unfortunately, the IPMI spec gives wiggle room to
the implementer to allow them to always have the alert enabled,
even if the driver doesn't enable it. So implement alerts.
If you don't in this situation, the SMBus alert handling will
constantly complain.
ipmi: Fix a problem that messages are not issued in run_to_completion mode
start_next_msg() issues a message placed in smi_info->waiting_msg
if it is non-NULL. However, sender() sets a message to
smi_info->curr_msg and NULL to smi_info->waiting_msg in the context
of run_to_completion mode. As the result, it leads an infinite
loop by waiting the completion of unissued message when leaving
dying message after kernel panic.
sender() should set the message to smi_info->waiting_msg not
curr_msg.
Gregory CLEMENT [Tue, 5 May 2015 23:24:05 +0000 (16:24 -0700)]
rtc: armada38x: fix concurrency access in armada38x_rtc_set_time
While setting the time, the RTC TIME register should not be accessed.
However due to hardware constraints, setting the RTC time involves
sleeping during 100ms. This sleep was done outside the critical section
protected by the spinlock, so it was possible to read the RTC TIME
register and get an incorrect value. This patch introduces a mutex for
protecting the RTC TIME access, unlike the spinlock it is allowed to
sleep in a critical section protected by a mutex.
The RTC STATUS register can still be used from the interrupt handler but
it has no effect on setting the time.
Junxiao Bi [Tue, 5 May 2015 23:24:02 +0000 (16:24 -0700)]
ocfs2: dlm: fix race between purge and get lock resource
There is a race window in dlm_get_lock_resource(), which may return a
lock resource which has been purged. This will cause the process to
hang forever in dlmlock() as the ast msg can't be handled due to its
lock resource not existing.
dlm_get_lock_resource {
...
spin_lock(&dlm->spinlock);
tmpres = __dlm_lookup_lockres_full(dlm, lockid, namelen, hash);
if (tmpres) {
spin_unlock(&dlm->spinlock);
>>>>>>>> race window, dlm_run_purge_list() may run and purge
the lock resource
spin_lock(&tmpres->spinlock);
...
spin_unlock(&tmpres->spinlock);
}
}
Ryusuke Konishi [Tue, 5 May 2015 23:24:00 +0000 (16:24 -0700)]
nilfs2: fix sanity check of btree level in nilfs_btree_root_broken()
The range check for b-tree level parameter in nilfs_btree_root_broken()
is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even
though the level is limited to values in the range of 0 to
(NILFS_BTREE_LEVEL_MAX - 1).
Since the level parameter is read from storage device and used to index
nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it
can cause memory overrun during btree operations if the boundary value
is set to the level parameter on device.
This fixes the broken sanity check and adds a comment to clarify that
the upper bound NILFS_BTREE_LEVEL_MAX is exclusive.
Guenter Roeck [Tue, 5 May 2015 23:23:57 +0000 (16:23 -0700)]
util_macros.h: have array pointer point to array of constants
Using the new find_closest() macro can result in the following sparse
warnings.
drivers/hwmon/lm85.c:194:16: warning:
incorrect type in initializer (different modifiers)
drivers/hwmon/lm85.c:194:16: expected int *__fc_a
drivers/hwmon/lm85.c:194:16: got int static const [toplevel] *<noident>
drivers/hwmon/lm85.c:210:16: warning:
incorrect type in initializer (different modifiers)
drivers/hwmon/lm85.c:210:16: expected int *__fc_a
drivers/hwmon/lm85.c:210:16: got int const *map
This is because the array passed to find_closest() will typically be
declared as array of constants, but the macro declares a non-constant
pointer to it.
Naoya Horiguchi [Tue, 5 May 2015 23:23:52 +0000 (16:23 -0700)]
mm/hwpoison-inject: check PageLRU of hpage
Hwpoison injector checks PageLRU of the raw target page to find out
whether the page is an appropriate target, but current code now filters
out thp tail pages, which prevents us from testing for such cases via this
interface. So let's check hpage instead of p.
Naoya Horiguchi [Tue, 5 May 2015 23:23:49 +0000 (16:23 -0700)]
mm/hwpoison-inject: fix refcounting in no-injection case
Hwpoison injection via debugfs:hwpoison/corrupt-pfn takes a refcount of
the target page. But current code doesn't release it if the target page
is not supposed to be injected, which results in memory leak. This patch
simply adds the refcount releasing code.
Naoya Horiguchi [Tue, 5 May 2015 23:23:46 +0000 (16:23 -0700)]
mm: soft-offline: fix num_poisoned_pages counting on concurrent events
If multiple soft offline events hit one free page/hugepage concurrently,
soft_offline_page() can handle the free page/hugepage multiple times,
which makes num_poisoned_pages counter increased more than once. This
patch fixes this wrong counting by checking TestSetPageHWPoison for normal
papes and by checking the return value of dequeue_hwpoisoned_huge_page()
for hugepages.
rtc: add rtc-abx80x, a driver for the Abracon AB x80x i2c rtc
This is a basic driver for the ultra-low-power Abracon AB x80x series of RTC
chips. It supports in particular, the supersets AB0805 and AB1805.
It allows reading and writing the time, and enables the supercapacitor/
battery charger.
Joe Perches [Tue, 5 May 2015 23:23:38 +0000 (16:23 -0700)]
kasan: show gcc version requirements in Kconfig and Documentation
The documentation shows a need for gcc > 4.9.2, but it's really >=. The
Kconfig entries don't show require versions so add them. Correct a
latter/later typo too. Also mention that gcc 5 required to catch out of
bounds accesses to global and stack variables.
Naoya Horiguchi [Tue, 5 May 2015 23:23:35 +0000 (16:23 -0700)]
mm/memory-failure: call shake_page() when error hits thp tail page
Currently memory_failure() calls shake_page() to sweep pages out from
pcplists only when the victim page is 4kB LRU page or thp head page.
But we should do this for a thp tail page too.
Consider that a memory error hits a thp tail page whose head page is on
a pcplist when memory_failure() runs. Then, the current kernel skips
shake_pages() part, so hwpoison_user_mappings() returns without calling
split_huge_page() nor try_to_unmap() because PageLRU of the thp head is
still cleared due to the skip of shake_page().
As a result, me_huge_page() runs for the thp, which is broken behavior.
One effect is a leak of the thp. And another is to fail to isolate the
memory error, so later access to the error address causes another MCE,
which kills the processes which used the thp.
This patch fixes this problem by calling shake_page() for thp tail case.
Yury Norov [Tue, 5 May 2015 23:23:33 +0000 (16:23 -0700)]
lib: delete lib/find_last_bit.c
The file lib/find_last_bit.c was no longer used and supposed to be
deleted by commit 8f6f19dd51 ("lib: move find_last_bit to
lib/find_next_bit.c") but that delete didn't happen. This gets rid of
it.
Minchan Kim [Tue, 5 May 2015 23:23:28 +0000 (16:23 -0700)]
zram: add Designated Reviewer for zram in MAINTAINERS
Sergey Senozhatsky has contributed/reviewed to zram for a long time. He
is really helpful for maintaining zram so I want for him to continue
helping me as Designated Reviewer unless he hates it.
David S. Miller [Tue, 5 May 2015 23:41:33 +0000 (19:41 -0400)]
Merge tag 'wireless-drivers-for-davem-2015-05-05' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
iwlwifi:
* fix firmware API for -13.ucode
* fix RSSI handling that avoid bad roaming decision
* fix firmware debug
* fix MFUART operation
* fix ASSERT while restart the hardware (because of another ASSERT e.g)
Yishai Hadas [Tue, 5 May 2015 14:07:12 +0000 (17:07 +0300)]
net/mlx4_core: Work properly with EQ numbers > 256 in SRIOV
The Firmware uses dynamic EQs allocation based on number of VFs and
max EQs that can be allocated. As a result, VF can have EQ numbers
that are larger than 256.
According to the firmware spec, the max value is limited to be 1024
(10 bits), adapt the relevant code accordingly. This bug was impossible
to hit prior to commit 7ae0e400cd93 ("net/mlx4_core: Flexible (asymmetric)
allocation of EQs and MSI-X vectors for PF/VFs") which actually enables
large number of EQs for VFs.
Eran Ben Elisha [Tue, 5 May 2015 14:07:11 +0000 (17:07 +0300)]
net/mlx4_en: Fix off-by-one in counters manipulation
This caused the en_stats_adder helper to accumulate a field which is
not related to the counter, fix that.
Fixes: a3333b35da16 ('net/mlx4_en: Moderate ethtool callback to show [..]') Signed-off-by: Eran Ben Elisha <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]>
hv_netvsc: remove unused variable in netvsc_send()
With commit b56fc3c53654 ("hv_netvsc: Fix a bug in netvsc_start_xmit()"),
skb variable is no longer used in netvsc_send. Remove variable and dead
code that depended on it.
Joe Perches [Sun, 22 Feb 2015 18:21:07 +0000 (10:21 -0800)]
ipmi: Remove incorrect use of seq_has_overflowed
commit d6c5dc18d863 ("ipmi: Remove uses of return value of seq_printf")
incorrectly changed the return value of various proc_show functions
to use seq_has_overflowed().
These functions should return 0 on completion rather than 1/true
on overflow. 1 is the same as #define SEQ_SKIP which would cause
the output to not be emitted (skipped) instead.
This is a logical defect only as the length of these outputs are
all smaller than the initial allocation done by the seq filesystem.
Marc Dionne [Mon, 4 May 2015 18:16:44 +0000 (15:16 -0300)]
x86: Make cpu_tss available to external modules
Commit 75182b1632 ("x86/asm/entry: Switch all C consumers of
kernel_stack to this_cpu_sp0()") changed current_thread_info
to use this_cpu_sp0, and indirectly made it rely on init_tss
which was exported with EXPORT_PER_CPU_SYMBOL_GPL.
As a result some macros and inline functions such as set/get_fs,
test_thread_flag and variants have been made unusable for
external modules.
Make cpu_tss exported with EXPORT_PER_CPU_SYMBOL so that these
functions are accessible again, as they were previously.
Boris Ostrovsky [Mon, 4 May 2015 15:02:15 +0000 (11:02 -0400)]
hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
attribute issue") makes AMD processors set SS to __KERNEL_DS in
__switch_to() to deal with cases when SS is NULL.
This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.
Since the problem that the commit is trying to address would have to be
fixed in the hypervisor (if it in fact exists under Xen) there is no
reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.
This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features
op which will clear this flag. (And since this structure is no longer
HVM-specific we should do some renaming).
Boris Ostrovsky [Wed, 29 Apr 2015 21:10:12 +0000 (17:10 -0400)]
xen/events: Clear cpu_evtchn_mask before resuming
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
cpu_evtchn_mask bits may be stale. This can happen even though
evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that
is passed in is not necessarily the original one (from pre-migration
times) but instead is freshly allocated during resume and so any
information about which CPU the channel was bound to is lost.
Thus we should clear the mask during resume.
We also need to make sure that bits for xenstore and console channels
are set when these two subsystems are resumed. While rebind_evtchn_irq()
(which is invoked for both of them on a resume) calls irq_set_affinity(),
the latter will in fact postpone setting affinity until handling the
interrupt. But because cpu_evtchn_mask will have bits for these two
cleared we won't be able to take the interrupt.
With that in mind, we need to bind those two channels explicitly in
rebind_evtchn_irq(). We will keep irq_set_affinity() so that we have a
pass through generic irq affinity code later, in case something needs
to be updated there as well.
(Also replace cpumask_of(0) with cpumask_of(info->cpu) in
rebind_evtchn_irq(): it should be set to zero in preceding
xen_irq_info_evtchn_setup().)
Since Roland stepped down, the community asked me to take his place, and
the nomination was followed by sufficient votes and no dissensions that
we can move forward with the change.
Chen Yu [Sun, 3 May 2015 14:35:05 +0000 (22:35 +0800)]
init: fix regression by supporting devices with major:minor:offset format
Commit 283e7ad02 ("init: stricter checking of major:minor root=
values") was so strict that it exposed the fact that a previously
unknown device format was being used.
Distributions like Ubuntu uses klibc (rather than uswsusp) to resume
system from hibernation. klibc expressed the swap partition/file in
the form of major:minor:offset. For example, 8:3:0 represents a swap
partition in klibc, and klibc's resume process in initrd will finally
echo 8:3:0 to /sys/power/resume for manually resuming. However, due
to commit 283e7ad02's stricter checking, 8:3:0 will be treated as an
invalid device format, and manual resuming from hibernation will fail.
Fix this by adding support for devices with major:minor:offset format
when resuming from hibernation.
The problem which that commit attempts to fix actually lies in the
Freescale CAAM crypto driver not dm-crypt.
dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto
driver should internally backlog requests which arrive when the queue is
full and process them later. Until the crypto hw's queue becomes full,
the driver returns -EINPROGRESS. When the crypto hw's queue if full,
the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is
expected to backlog the request and process it when the hardware has
queue space. At the point when the driver takes the request from the
backlog and starts processing it, it calls the completion function with
a status of -EINPROGRESS. The completion function is called (for a
second time, in the case of backlogged requests) with a status/err of 0
when a request is done.
Crypto drivers for hardware without hardware queueing use the helpers,
crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request()
and crypto_get_backlog() helpers to implement this behaviour correctly,
while others implement this behaviour without these helpers (ccp, for
example).
dm-crypt (before the patch that needs reverting) uses this API
correctly. It queues up as many requests as the hw queues will allow
(i.e. as long as it gets back -EINPROGRESS from the request function).
Then, when it sees at least one backlogged request (gets -EBUSY), it
waits till that backlogged request is handled (completion gets called
with -EINPROGRESS), and then continues. The references to
af_alg_wait_for_completion() and af_alg_complete() in that commit's
commit message are irrelevant because those functions only handle one
request at a time, unlink dm-crypt.
The problem is that the Freescale CAAM driver, which that commit
describes as having being tested with, fails to implement the
backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware
queue is full, it simply returns -EBUSY without backlogging the request.
What the observed deadlock was is not described in the commit message
but it is obviously the wait_for_completion() in crypto_convert() where
dm-crypto would wait for the completion being called with -EINPROGRESS
in the case of backlogged requests. This completion will never be
completed due to the bug in the CAAM driver.
Commit 0618764cb25 incorrectly made dm-crypt wait for every request,
even when the driver/hardware queues are not full, which means that
dm-crypt will never see -EBUSY. This means that that commit will cause
a performance regression on all crypto drivers which implement the API
correctly.
Revert it. Correct backlog handling should be implemented in the CAAM
driver instead.
Cc'ing stable purely because commit 0618764cb25 did. If for some reason
a stable@ kernel did pick up commit 0618764cb25 it should get reverted.
Pull crypto fixes from Herbert Xu:
"This fixes a build problem with bcm63xx and yet another fix to the
memzero_explicit function to ensure that the memset is not elided"
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
hwrng: bcm63xx - Fix driver compilation
lib: make memzero_explicit more robust against dead store elimination
Linus Torvalds [Tue, 5 May 2015 15:42:06 +0000 (08:42 -0700)]
Merge tag 'media/v4.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
"Three driver fixes:
- fix for omap4, fixing a regression due to a subsystem API that got
removed for 4.1 (commit efde234674d9);
- fix for one of the formats supported by Marvel ccic driver;
- fix rcar_vin driver that, when stopping abnormally, the driver
can't return from wait_for_completion"
* tag 'media/v4.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] v4l: omap4iss: Replace outdated OMAP4 control pad API with syscon
[media] media: soc_camera: rcar_vin: Fix wait_for_completion
[media] marvell-ccic: fix Y'CbCr ordering
Dan Carpenter [Tue, 21 Apr 2015 13:46:28 +0000 (16:46 +0300)]
efi: Fix error handling in add_sysfs_runtime_map_entry()
I spotted two (difficult to hit) bugs while reviewing this.
1) There is a double free bug because we unregister "map_kset" in
add_sysfs_runtime_map_entry() and also efi_runtime_map_init().
2) If we fail to allocate "entry" then we should return
ERR_PTR(-ENOMEM) instead of NULL.
Lukas Wunner [Mon, 4 May 2015 13:06:49 +0000 (15:06 +0200)]
drm/i915: Add missing MacBook Pro models with dual channel LVDS
Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models
shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz)
as a BTO option, both versions used dual channel LVDS even though
the smaller one would have fit into a single channel.
Notes:
Bug report showing that the MacBookPro8,2 with 1440x900 uses dual
channel LVDS (this lead to it being hardcoded in intel_lvds.c by
Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc):
https://bugzilla.kernel.org/show_bug.cgi?id=42842
If i915.lvds_channel_mode=2 is missing even though the machine needs
it, every other vertical line is white and consequently, only the left
half of the screen is visible (verified by myself on a MacBookPro9,1).
Forum posting concerning a MacBookPro6,2 with 1440x900, author is
using i915.lvds_channel_mode=2 on the kernel command line, proving
that the machine uses dual channels:
https://bbs.archlinux.org/viewtopic.php?id=185770
Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all
MacBook Pro "A1286" models, and that model number encompasses the
MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's
driven with dual channel LVDS:
http://www.ebay.com/itm/-/400690878560
http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286
http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf
Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones
with i915 graphics and dual channel LVDS, so that list should be
complete. And the 8,2 is already in intel_lvds.c.
Possible motivation to use dual channel LVDS even on the 1440x900
models: Reduce the number of different parts, i.e. use identical logic
boards and display cabling on both versions and the only differing
component is the panel.
drm/i915: Assume dual channel LVDS if pixel clock necessitates it
Single channel LVDS maxes out at 112 MHz, anything above must be dual
channel. This avoids the need to specify i915.lvds_channel_mode=2 on
all 17" MacBook Pro models with i915 graphics since they had 1920x1200
(193 MHz), plus those 15" pre-retina models which had a resolution
of 1680x1050 (119 MHz) as a BTO option.
Source for 112 MHz limit of single channel LVDS is section 2.3 of:
https://01.org/linuxgraphics/sites/default/files/documentation/ivb_ihd_os_vol3_part4.pdf
v2: Avoid hardcoding 17" models by assuming dual channel LVDS if the
resolution necessitates it, suggested by Jani Nikula.
v3: Fix typo, thanks Joonas Lahtinen.
v4: Split commit in two, suggested by Ville Syrjälä.
The rockchip iommu driver references its of_device_id table
from the init function, which fails to build when the table
is undefined:
iommu/rockchip-iommu.c: In function 'rk_iommu_init':
iommu/rockchip-iommu.c:1029:35: error: 'rk_iommu_dt_ids' undeclared (first use in this function)
np = of_find_matching_node(NULL, rk_iommu_dt_ids);
This removes the #ifdef and the corresponding of_match_ptr wrapper
to make it build both with CONFIG_OF enabled or disabled.
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
The qib driver uses a mmap() special case for when PAT is
not used, this behaviour used to be determined with a
module parameter but since we have been asked to just
remove that module parameter this checks for the WC cookie,
if not set we can assume PAT was used. If its set we do
what we used to do for the mmap for when MTRR was enabled.
The removal of the module parameter is OK given that Andy
notes that even if users of module parameter are still around
it will not prevent loading of the module on recent kernels.
Guy Shapiro [Wed, 15 Apr 2015 15:17:57 +0000 (18:17 +0300)]
IB/core: dma unmap optimizations
While unmapping an ODP writable page, the dirty bit of the page is set. In
order to do so, the head of the compound page is found.
Currently, the compound head is found even on non-writable pages, where it is
never used, leading to unnecessary cpu barrier that impacts performance.
This patch moves the search for the compound head to be done only when needed.
Guy Shapiro [Wed, 15 Apr 2015 15:17:56 +0000 (18:17 +0300)]
IB/core: dma map/unmap locking optimizations
Currently, while mapping or unmapping pages for ODP, the umem mutex is locked
and unlocked once for each page. Such lock/unlock operation take few tens to
hundreds of nsecs. This makes a significant impact when mapping or unmapping few
MBs of memory.
To avoid this, the mutex should be locked only once per operation, and not per
page.
RDMA/nes: Report the actual address of the remote connecting peer
Get the actual (non-mapped) ip/tcp address of the connecting peer from
the port mapper and report the address info to the user space application
at the time of connection establishment
RDMA/core: Enable the iWarp Port Mapper to provide the actual address of the connecting peer to its clients
Add functionality to enable the port mapper on the passive side to provide to its
clients the actual (non-mapped) ip/tcp address information of the connecting peer
1) Adding remote_info_cb() to process the address info of the connecting peer
The address info is provided by the user space port mapper service when
the connection is initiated by the peer
2) Adding a hash list to store the remote address info
3) Adding functionality to add/remove the remote address info
After the info has been provided to the port mapper client,
it is removed from the hash list
Hariprasad S [Tue, 21 Apr 2015 20:15:01 +0000 (01:45 +0530)]
iw_cxgb4: enforce qp/cq id requirements
Currently the iw_cxgb4 implementation requires the qp and cq qid densities
to match as well as the qp and cq id ranges. So fail a device open if
the device configuration doesn't meet the requirements.
The reason for these restictions has to do with the fact that IQ qid X
has a UGTS register in the same bar2 page as EQ qid X. Thus both qids
need to be allocated to the same user process for security reasons.
The logic that does this (the qpid allocator in iw_cxgb4/resource.c)
handles this but requires the above restrictions.
Jason Gunthorpe [Mon, 20 Apr 2015 20:01:11 +0000 (14:01 -0600)]
RDMA/CMA: Canonize IPv4 on IPV6 sockets properly
When accepting a new IPv4 connect to an IPv6 socket, the CMA tries to
canonize the address family to IPv4, but does not properly process
the listening sockaddr to get the listening port, and does not properly
set the address family of the canonized sockaddr.
Jungseung Lee [Mon, 4 May 2015 10:33:48 +0000 (11:33 +0100)]
arm64: mm: Fix build error with CONFIG_SPARSEMEM_VMEMMAP disabled
This fix the below build error:
arch/arm64/mm/dump.c: In function ‘ptdump_init’:
arch/arm64/mm/dump.c:331:18: error: ‘VMEMMAP_START_NR’ undeclared (first use in this function)
address_markers[VMEMMAP_START_NR].start_address =
^
arch/arm64/mm/dump.c:331:18: note: each undeclared identifier is reported only once for each
function it appears in
arch/arm64/mm/dump.c:333:18: error: ‘VMEMMAP_END_NR’ undeclared (first use in this function)
address_markers[VMEMMAP_END_NR].start_address =
^ Acked-by: Laura Abbott <[email protected]> Signed-off-by: Jungseung Lee <[email protected]> Signed-off-by: Will Deacon <[email protected]>
It turns out that there are a couple of problems with the way we're
fixing up branch instructions used as part of alternative instruction
sequences:
(1) If the branch target is also in the alternative sequence, we'll
generate a branch into the .altinstructions section which actually
gets freed.
(2) The calls to aarch64_insn_{read,write} bring an awful lot more
code into the patching path (e.g. taking locks, poking the fixmap,
invalidating the TLB) which isn't actually needed for the early
patching run under stop_machine, but makes the use of alternative
sequences extremely fragile (as we can't patch code that could be
used by the patching code).
Given that no code actually requires alternative patching of immediate
branches, let's remove this support for now and revisit it when we've
got a user. We leave the updated size check, since we really do require
the sequences to be the same length.
Tahsin Erdogan [Tue, 5 May 2015 04:15:31 +0000 (21:15 -0700)]
x86/spinlocks: Fix regression in spinlock contention detection
A spinlock is regarded as contended when there is at least one waiter.
Currently, the code that checks whether there are any waiters rely on
tail value being greater than head. However, this is not true if tail
reaches the max value and wraps back to zero, so arch_spin_is_contended()
incorrectly returns 0 (not contended) when tail is smaller than head.
The original code (before regression) handled this case by casting the
(tail - head) to an unsigned value. This change simply restores that
behavior.
Jaegeuk Kim [Tue, 21 Apr 2015 17:40:54 +0000 (10:40 -0700)]
Revert "f2fs: enhance multi-threads performance"
This reports performance regression by Yuanhan Liu.
The basic idea was to reduce one-point mutex, but it turns out this causes
another contention like context swithes.
https://lkml.org/lkml/2015/4/21/11
Until finishing the analysis on this issue, I'd like to revert this for a while.
Shaohua Li [Mon, 4 May 2015 20:32:48 +0000 (14:32 -0600)]
blk-mq: don't lose requests if a stopped queue restarts
Normally if driver is busy to dispatch a request the logic is like below:
block layer: driver:
__blk_mq_run_hw_queue
a. blk_mq_stop_hw_queue
b. rq add to ctx->dispatch
But it's possible step 1-2 runs between a and b. And since rq isn't in
ctx->dispatch yet, step 2 will not run rq. The rq might get lost if
there are no subsequent requests kick in.
David S. Miller [Mon, 4 May 2015 20:00:55 +0000 (16:00 -0400)]
Merge tag 'mac80211-for-davem-2015-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
We have only a few fixes right now:
* a fix for an issue with hash collision handling in the
rhashtable conversion
* a merge issue - rhashtable removed default shrinking
just before mac80211 was converted, so enable it now
* remove an invalid WARN that can trigger with legitimate
userspace behaviour
* add a struct member missing from kernel-doc that caused
a lot of warnings
====================
Yuval Mintz [Mon, 4 May 2015 09:34:12 +0000 (12:34 +0300)]
bnx2x: Fix to prevent inner-reload
Submit 909d9faae2a44 ("bnx2x: Prevent inner-reload while VFs exist")
contained a bug - MTU change was not prevented by it; Instead, it
`randomally' prevented bnx2x_resume() from running [harmless yet wrong].
Here's the first bluetooth-next pull request for 4.2:
- Various fixes for at86rf230 driver
- ieee802154: trace events support for rdev->ops
- HCI UART driver refactoring
- New Realtek IDs added to btusb driver
- Off-by-one fix for rtl8723b in btusb driver
- Refactoring of btbcm driver for both UART & USB use
Please let me know if there are any issues pulling. Thanks.
====================
David Ahern [Mon, 4 May 2015 15:51:38 +0000 (11:51 -0400)]
net/rds: Fix new sparse warning
c0adf54a109 introduced new sparse warnings:
CHECK /home/dahern/kernels/linux.git/net/rds/ib_cm.c
net/rds/ib_cm.c:191:34: warning: incorrect type in initializer (different base types)
net/rds/ib_cm.c:191:34: expected unsigned long long [unsigned] [usertype] dp_ack_seq
net/rds/ib_cm.c:191:34: got restricted __be64 <noident>
net/rds/ib_cm.c:194:51: warning: cast to restricted __be64
The temporary variable for sequence number should have been declared as __be64
rather than u64. Make it so.
Kamlakant Patel [Mon, 4 May 2015 09:09:49 +0000 (14:39 +0530)]
net/smsc911x: fix irq resource allocation failure
When smsc911x uses GPIO as the interrupt controller, and if both are
loaded as modules, we get following error:
"smsc911x: Could not allocate irq resource"
This issue is because of smsc911x using platform_get_resource to get
device tree based irq resource.
commit "9ec36ca (of/irq: do irq resolution in platform_get_irq)" and
commit "7085a7 (drivers: platform: parse IRQ flags from resources)" add
support in platform_get_irq to resolve irq and irq_flags respectively
for both modern device tree and legacy static platform data platforms.
Modify smsc911x driver to use platform_get_irq to pick up irq resource
correctly and use irq_get_trigger_type to get the IRQ trigger flags.
Shaohua Li [Fri, 1 May 2015 16:59:44 +0000 (09:59 -0700)]
blk-mq: fix FUA request hang
When a FUA request enters its DATA stage of flush pipeline, the
request is added to mq requeue list, the request will then be added to
ctx->rq_list. blk_mq_attempt_merge() might merge the request with a bio.
Later when the request is finished the flush pipeline, the
request->__data_len is 0. Then I only saw the bio gets endio called, the
original request never finish.
Adding REQ_FLUSH_SEQ into REQ_NOMERGE_FLAGS looks an easy fix.
Vlad Yasevich [Sun, 3 May 2015 01:33:44 +0000 (21:33 -0400)]
net: core: Correct an over-stringent device loop detection.
The code in __netdev_upper_dev_link() has an over-stringent
loop detection logic that actually prevents valid configurations
from working correctly.
In particular, the logic returns an error if an upper device
is already in the list of all upper devices for a given dev.
This particular check seems to be a overzealous as it disallows
perfectly valid configurations. For example:
# ip l a link eth0 name eth0.10 type vlan id 10
# ip l a dev br0 typ bridge
# ip l s eth0.10 master br0
# ip l s eth0 master br0 <--- Will fail
If you switch the last two commands (add eth0 first), then both
will succeed. If after that, you remove eth0 and try to re-add
it, it will fail!
It appears to be enough to simply check adj_list to keeps things
safe.
I've tried stacking multiple devices multiple times in all different
combinations, and either rx_handler registration prevented the stacking
of the device linking cought the error.
Tilman Schmidt [Sat, 2 May 2015 17:23:22 +0000 (19:23 +0200)]
isdn/gigaset: cede maintainership
As German phone operators are discontinuing ISDN service, neither
Hansjörg nor I will be able to maintain the Gigaset ISDN drivers
any longer. Paul Bolle offered to step into the breach for odd
fixes.
projects / linux.git / log