| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
With the recent nohz scheduler changes, rq's nohz flag
'NOHZ_TICK_STOPPED' and its associated state doesn't get cleared
immediately after the cpu exits idle. This gets cleared as part
of the next tick seen on that cpu.
For the cpu offline support, we need to clear this state
manually. Fix it by registering a cpu notifier, which clears the
nohz idle load balance state for this rq explicitly during the
CPU_DYING notification.
There won't be any nohz updates for that cpu, after the
CPU_DYING notification. But lets be extra paranoid and skip
updating the nohz state in the select_nohz_load_balancer() if
the cpu is not in active state anymore.
Reported-by: Srivatsa S. Bhat <[email protected]>
Reviewed-and-tested-by: Srivatsa S. Bhat <[email protected]>
Tested-by: Sergey Senozhatsky <[email protected]>
Signed-off-by: Suresh Siddha <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Commit 029632fbb7b7c9d85063cc9eb470de6c54873df3 ("sched: Make
separate sched*.c translation units") removed the include of
asm/mutex.h from sched.c.
This breaks the combination of:
CONFIG_MUTEX_SPIN_ON_OWNER=yes
CONFIG_HAVE_ARCH_MUTEX_CPU_RELAX=yes
like s390 without mutex debugging:
CC kernel/sched/core.o
kernel/sched/core.c: In function ‘mutex_spin_on_owner’:
kernel/sched/core.c:3287: error: implicit declaration of function ‘arch_mutex_cpu_relax’
Lets re-add the include to kernel/sched/core.c
Signed-off-by: Christian Borntraeger <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
KOSAKI Motohiro noticed the following race:
> CPU0 CPU1
> --------------------------------------------------------
> deactivate_task()
> task->state = TASK_UNINTERRUPTIBLE;
> activate_task()
> rq->nr_uninterruptible--;
>
> schedule()
> deactivate_task()
> rq->nr_uninterruptible++;
>
Kosaki-San's scenario is possible when CPU0 runs
__sched_setscheduler() against CPU1's current @task.
__sched_setscheduler() does a dequeue/enqueue in order to move
the task to its new queue (position) to reflect the newly provided
scheduling parameters. However it should be completely invariant to
nr_uninterruptible accounting, sched_setscheduler() doesn't affect
readyness to run, merely policy on when to run.
So convert the inappropriate activate/deactivate_task usage to
enqueue/dequeue_task, which avoids the nr_uninterruptible accounting.
Also convert the two other sites: __migrate_task() and
normalize_task() that still use activate/deactivate_task. These sites
aren't really a problem since __migrate_task() will only be called on
non-running task (and therefore are immume to the described problem)
and normalize_task() isn't ever used on regular systems.
Also remove the comments from activate/deactivate_task since they're
misleading at best.
Reported-by: KOSAKI Motohiro <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Link: http://lkml.kernel.org/r/1327486224.2614.45.camel@laptop
Signed-off-by: Ingo Molnar <[email protected]>
|
|
In error cleanup of agp_backend_initialize() and in agp_backend_cleanup(),
agp_destroy_page() is passed virtual address of the scratch page. This
leads to a kernel warning if the initialization fails (or upon regular
cleanup) as pointer to struct page should be passed instead.
Signed-off-by: Michal Kubecek <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
When a new net namespace is created, we should attach to it a "struct
net_generic" with enough slots (even empty), or we can hit the following
BUG_ON() :
[ 200.752016] kernel BUG at include/net/netns/generic.h:40!
...
[ 200.752016] [<ffffffff825c3cea>] ? get_cfcnfg+0x3a/0x180
[ 200.752016] [<ffffffff821cf0b0>] ? lockdep_rtnl_is_held+0x10/0x20
[ 200.752016] [<ffffffff825c41be>] caif_device_notify+0x2e/0x530
[ 200.752016] [<ffffffff810d61b7>] notifier_call_chain+0x67/0x110
[ 200.752016] [<ffffffff810d67c1>] raw_notifier_call_chain+0x11/0x20
[ 200.752016] [<ffffffff821bae82>] call_netdevice_notifiers+0x32/0x60
[ 200.752016] [<ffffffff821c2b26>] register_netdevice+0x196/0x300
[ 200.752016] [<ffffffff821c2ca9>] register_netdev+0x19/0x30
[ 200.752016] [<ffffffff81c1c67a>] loopback_net_init+0x4a/0xa0
[ 200.752016] [<ffffffff821b5e62>] ops_init+0x42/0x180
[ 200.752016] [<ffffffff821b600b>] setup_net+0x6b/0x100
[ 200.752016] [<ffffffff821b6466>] copy_net_ns+0x86/0x110
[ 200.752016] [<ffffffff810d5789>] create_new_namespaces+0xd9/0x190
net_alloc_generic() should take into account the maximum index into the
ptr array, as a subsystem might use net_generic() anytime.
This also reduces number of reallocations in net_assign_generic()
Reported-by: Sasha Levin <[email protected]>
Tested-by: Sasha Levin <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Sjur Brændeland <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Cc: Pavel Emelyanov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
into drm-fixes
* 'drm-intel-fixes' of git://people.freedesktop.org/~keithp/linux: (24 commits)
drm/i915: fixup forcewake spinlock fallout in drpc debugfs function
drm/i915: debugfs: show semaphore registers also on gen7
drm/i915: allow userspace forcewake references also on gen7
drm/i915: Re-enable gen7 RC6 and GPU turbo after resume.
drm/i915: Correct debugfs printout for RC1e.
Revert "drm/i915: Work around gen7 BLT ring synchronization issues."
drm/i915: rip out the HWSTAM missed irq workaround
drm/i915: paper over missed irq issues with force wake voodoo
drm/i915: Hold gt_lock across forcewake register reads
drm/i915: Hold gt_lock during reset
drm/i915: Move reset forcewake processing to gen6_do_reset
drm/i915: protect force_wake_(get|put) with the gt_lock
drm/i915: convert force_wake_get to func pointer in the gpu reset code
drm/i915: sprite init failure on pre-SNB is not a failure
drm/i915: VBT Parser cleanup for eDP block
drm/i915: mask transcoder select bits before setting them on LVDS
drm/i915: Add Clientron E830 to the ignore LVDS list
CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB
drm/i915: handle 3rd pipe
drm/i915: simplify pipe checking
...
|
|
The very same problem is seen on Haier W18 laptop with ALC861 as seen
on ASUS A6Rp, which was fixed by the commit 3b25eb69.
Now we just need to add a new SSID entry pointing to the same fixup.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42656
Cc: <[email protected]> [v3.2+]
Signed-off-by: Takashi Iwai <[email protected]>
|
|
This is needed as otherwise we can get the following when
dealing with buggy data in a pinmux driver for
pinmux_search_function:
Unable to handle kernel NULL pointer dereference at virtual
address 00000000
...
PC is at strcmp+0xc/0x34
LR is at pinmux_get+0x350/0x8f4
...
As we need pctldev initialized to call ops->list_functions,
let's initialize it before check_ops calls and pass the
pctldev to the check_ops functions. Do this for both pinmux
and pinconf check_ops functions.
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The ctrl_dev_name is optional for struct pinmux_map assuming
that ctrl_dev is set. Without this patch we can get:
Unable to handle kernel NULL pointer dereference at virtual
address 00000000
...
(pinmux_hog_maps+0xa4/0x20c)
(pinctrl_register+0x2a4/0x378)
...
Fix this by adding adding a test for map->ctrl_dev.
Additionally move the test for map->ctrl_dev earlier
to optimize out the loop a bit.
Signed-off-by: Tony Lindgren <[email protected]>
Acked-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Fix some pinmux typos so implementing pinmux drivers
is a bit easier.
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
when != iounmap(e)
*if (...)
{ ... when != iounmap(e)
return ...; }
... when any
iounmap(e);
// </smpl>
Signed-off-by: Julia Lawall <[email protected]>
Signed-off-by: Sascha Hauer <[email protected]>
|
|
Fix the following build error found when building imx_v4_v5_defconfig:
CC arch/arm/mach-imx/mach-imx27ipcam.o
In file included from arch/arm/plat-mxc/include/mach/iomux-mx27.h:23,
from arch/arm/mach-imx/mach-imx27ipcam.c:22:
arch/arm/plat-mxc/include/mach/iomux-v1.h:99: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imx_iomuxv1_init'
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Sascha Hauer <[email protected]>
|
|
We've decided to provide CPU family specific container files
(starting with CPU family 15h). E.g. for family 15h we have to
load microcode_amd_fam15h.bin instead of microcode_amd.bin
Rationale is that starting with family 15h patch size is larger
than 2KB which was hard coded as maximum patch size in various
microcode loaders (not just Linux).
Container files which include patches larger than 2KB cause
different kinds of trouble with such old patch loaders. Thus we
have to ensure that the default container file provides only
patches with size less than 2KB.
Signed-off-by: Andreas Herrmann <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
[ documented the naming convention and tidied the code a bit. ]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
That is the last one missing for those CPUs.
Others were recently added with commits
fb215366b3c7320ac25dca766a0152df16534932
(KVM: expose latest Intel cpu new features (BMI1/BMI2/FMA/AVX2) to guest)
and
commit 969df4b82904a30fef19a67398a0c854d223ea67
(x86: Report cpb and eff_freq_ro flags correctly)
Signed-off-by: Andreas Herrmann <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
apply_uV is errornously set when regulator is instantiated from device
tree, even when it doesn't contain any voltage constraints.
This commit fixes error:
machine_constraints_voltage: CHARGER: failed to apply 0uV constraint
for following regulator description in DTS:
CHARGER {
regulator-min-microamp = <100000>;
regulator-max-microamp = <200000>;
}
Signed-off-by: Karol Lewandowski <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
We allocate memory with malloc(), but neglect to free it before
the variable 'phdrs' goes out of scope --> leak.
Signed-off-by: Jesper Juhl <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
[ Mostly harmless. ]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
EDAC detection no longer crashes multi-node systems, so don't
conflict on it with NumaChip.
Signed-off-by: Daniel J Blueman <[email protected]>
Cc: Steffen Persvold <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Initialize two spinlocks in tlb_uv.c and also properly define/initialize
the uv_irq_lock.
The lack of explicit initialization seems to be functionally
harmless, but it is diagnosed when these are turned on:
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_LOCKDEP=y
Signed-off-by: Cliff Wickman <[email protected]>
Cc: <[email protected]>
Cc: Dimitri Sivanich <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
[ Added the uv_irq_lock initialization fix by Dimitri Sivanich ]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
uv_gpa_to_soc_phys_ram() was inadvertently ignoring the
shift values. This fix takes the shift into account.
Signed-off-by: Russ Anderson <[email protected]>
Cc: <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: sha512 - reduce stack usage to safe number
crypto: sha512 - make it work, undo percpu message schedule
|
|
Port autoselection finds a port and then drop the lock,
then right after that, gets the hash bucket again and lock it.
Fix it to go direct.
Signed-off-by: Flavio Leitner <[email protected]>
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The current code checks for conflicts when the application
requests a specific port. If there is no conflict, then
the request is granted.
On the other hand, the port autoselection done by the kernel
fails when all ports are bound even when there is a port
with no conflict available.
The fix changes port autoselection to check if there is a
conflict and use it if not.
Signed-off-by: Flavio Leitner <[email protected]>
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When a packet is received on an L2TP IP socket (L2TPv3 IP link
encapsulation), the l2tpip socket's backlog_rcv function calls
xfrm4_policy_check(). This is not necessary, since it was called
before the skb was added to the backlog. With CONFIG_NET_NS enabled,
xfrm4_policy_check() will oops if skb->dev is null, so this trivial
patch removes the call.
This bug has always been present, but only when CONFIG_NET_NS is
enabled does it cause problems. Most users are probably using UDP
encapsulation for L2TP, hence the problem has only recently
surfaced.
EIP: 0060:[<c12bb62b>] EFLAGS: 00210246 CPU: 0
EIP is at l2tp_ip_recvmsg+0xd4/0x2a7
EAX: 00000001 EBX: d77b5180 ECX: 00000000 EDX: 00200246
ESI: 00000000 EDI: d63cbd30 EBP: d63cbd18 ESP: d63cbcf4
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Call Trace:
[<c1218568>] sock_common_recvmsg+0x31/0x46
[<c1215c92>] __sock_recvmsg_nosec+0x45/0x4d
[<c12163a1>] __sock_recvmsg+0x31/0x3b
[<c1216828>] sock_recvmsg+0x96/0xab
[<c10b2693>] ? might_fault+0x47/0x81
[<c10b2693>] ? might_fault+0x47/0x81
[<c1167fd0>] ? _copy_from_user+0x31/0x115
[<c121e8c8>] ? copy_from_user+0x8/0xa
[<c121ebd6>] ? verify_iovec+0x3e/0x78
[<c1216604>] __sys_recvmsg+0x10a/0x1aa
[<c1216792>] ? sock_recvmsg+0x0/0xab
[<c105a99b>] ? __lock_acquire+0xbdf/0xbee
[<c12d5a99>] ? do_page_fault+0x193/0x375
[<c10d1200>] ? fcheck_files+0x9b/0xca
[<c10d1259>] ? fget_light+0x2a/0x9c
[<c1216bbb>] sys_recvmsg+0x2b/0x43
[<c1218145>] sys_socketcall+0x16d/0x1a5
[<c11679f0>] ? trace_hardirqs_on_thunk+0xc/0x10
[<c100305f>] sysenter_do_call+0x12/0x38
Code: c6 05 8c ea a8 c1 01 e8 0c d4 d9 ff 85 f6 74 07 3e ff 86 80 00 00 00 b9 17 b6 2b c1 ba 01 00 00 00 b8 78 ed 48 c1 e8 23 f6 d9 ff <ff> 76 0c 68 28 e3 30 c1 68 2d 44 41 c1 e8 89 57 01 00 83 c4 0c
Signed-off-by: James Chapman <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Quoth Ben Myers:
"Please pull in the following bugfix for xfs. We forgot to drop a lock on
error in xfs_readlink. It hasn't been through -next yet, but there is no
-next tree tomorrow. The fix is clear so I'm sending this request today."
* 'for-linus' of git://oss.sgi.com/xfs/xfs:
xfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink()
|
|
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/ttm: fix two regressions since move_notify changes
drm/radeon: avoid deadlock if GPU lockup is detected in ib_pool_get
drm/radeon: silence out possible lock dependency warning
drm: Fix authentication kernel crash
gma500: Fix shmem mapping
drm/radeon/kms: refine TMDS dual link checks
drm/radeon/kms: use drm_detect_hdmi_monitor for picking encoder mode
drm/radeon/kms: rework modeset sequence for DCE41 and DCE5
drm/radeon/kms: move panel mode setup into encoder mode set
drm/radeon/kms: move disp eng pll setup to init path
drm/radeon: finish getting bios earlier
drm/radeon: fix invalid memory access in radeon_atrm_get_bios()
drm/radeon/kms: add some missing semaphore init
drm/radeon/kms: Add an MSI quirk for Dell RS690
gpu, drm, sis: Don't return uninitialized variable from sis_driver_load()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
* 'fix/asoc' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: wm2000: Fix use-after-free - don't release_firmware() twice on error
ASoC: wm8958: Use correct format string in dev_err() call
ASoC: wm8996: Call _POST_PMU callback for CPVDD
ASoC: mxs: Fix mxs-saif timeout
ASoC: Disable register synchronisation for low frequency WM8996 SYSCLK
ASoC: Don't go through cache when applying WM5100 rev A updates
ASoC: Mark WM5100 register map cache only when going into BIAS_OFF
ASoC: tlv320aic32x4: always enable analouge block
ASoC: tlv320aic32x4: always enable dividers
ASoC: sgtl5000: Fix wrong register name in restore
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
A fairly simple bugfix for a WARN_ON() which was triggered in the cache
reset support as a result of some subsequent work. There's only one
mainline user for the code path that's updated right now (wm8994) so
should be low risk.
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: Reset cache status when reinitialsing the cache
|
|
The data encryption was moved from ecryptfs_write_end into
ecryptfs_writepage, this patch moves the corresponding function
comments to be consistent with the modification.
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs
Says Tyler:
"Tim's logging message update will be really helpful to users when
they're trying to locate a problematic file in the lower filesystem
with filename encryption enabled.
You'll recognize the fix from Li, as you commented on that.
You should also be familiar with my setattr/truncate improvements,
since you were the one that pointed them out to us (thanks again!).
Andrew noted the /dev/ecryptfs write count sanitization needed to be
improved, so I've got a fix in there for that along with some other
less important cleanups of the /dev/ecryptfs read/write code."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
eCryptfs: Fix oops when printing debug info in extent crypto functions
eCryptfs: Remove unused ecryptfs_read()
eCryptfs: Check inode changes in setattr
eCryptfs: Make truncate path killable
eCryptfs: Infinite loop due to overflow in ecryptfs_write()
eCryptfs: Replace miscdev read/write magic numbers
eCryptfs: Report errors in writes to /dev/ecryptfs
eCryptfs: Sanitize write counts of /dev/ecryptfs
ecryptfs: Remove unnecessary variable initialization
ecryptfs: Improve metadata read failure logging
MAINTAINERS: Update eCryptfs maintainer address
|
|
Otherwise we won't resync later.
Signed-off-by: Mark Brown <[email protected]>
|
|
Otherwise we won't resync later.
Signed-off-by: Mark Brown <[email protected]>
|
|
Otherwise we won't resync later.
Signed-off-by: Mark Brown <[email protected]>
|
|
When a TD length mismatch is found during isoc TRB enqueue, it directly
returns -EINVAL. However, isoc transfer is partially enqueued at this time,
and the ring should be cleared.
This should be backported to kernels as old as 2.6.36, which contain the
commit 522989a27c7badb608155b1f1dea3487ed431f74 "xhci: Fix failed
enqueue in the middle of isoch TD."
Signed-off-by: Andiry Xu <[email protected]>
Signed-off-by: Sarah Sharp <[email protected]>
Cc: [email protected]
|
|
If pages passed to the eCryptfs extent-based crypto functions are not
mapped and the module parameter ecryptfs_verbosity=1 was specified at
loading time, a NULL pointer dereference will occur.
Note that this wouldn't happen on a production system, as you wouldn't
pass ecryptfs_verbosity=1 on a production system. It leaks private
information to the system logs and is for debugging only.
The debugging info printed in these messages is no longer very useful
and rather than doing a kmap() in these debugging paths, it will be
better to simply remove the debugging paths completely.
https://launchpad.net/bugs/913651
Signed-off-by: Tyler Hicks <[email protected]>
Reported-by: Daniel DeFreez
Cc: <[email protected]>
|
|
ecryptfs_read() has been ifdef'ed out for years now and it was
apparently unused before then. It is time to get rid of it for good.
Signed-off-by: Tyler Hicks <[email protected]>
|
|
Most filesystems call inode_change_ok() very early in ->setattr(), but
eCryptfs didn't call it at all. It allowed the lower filesystem to make
the call in its ->setattr() function. Then, eCryptfs would copy the
appropriate inode attributes from the lower inode to the eCryptfs inode.
This patch changes that and actually calls inode_change_ok() on the
eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call
would happen earlier in ecryptfs_setattr(), but there are some possible
inode initialization steps that must happen first.
Since the call was already being made on the lower inode, the change in
functionality should be minimal, except for the case of a file extending
truncate call. In that case, inode_newsize_ok() was never being
called on the eCryptfs inode. Rather than inode_newsize_ok() catching
maximum file size errors early on, eCryptfs would encrypt zeroed pages
and write them to the lower filesystem until the lower filesystem's
write path caught the error in generic_write_checks(). This patch
introduces a new function, called ecryptfs_inode_newsize_ok(), which
checks if the new lower file size is within the appropriate limits when
the truncate operation will be growing the lower file.
In summary this change prevents eCryptfs truncate operations (and the
resulting page encryptions), which would exceed the lower filesystem
limits or FSIZE rlimits, from ever starting.
Signed-off-by: Tyler Hicks <[email protected]>
Reviewed-by: Li Wang <[email protected]>
Cc: <[email protected]>
|
|
ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a
page, zeroes out the appropriate portions, and then encrypts the page
before writing it to the lower filesystem. It was unkillable and due to
the lack of sparse file support could result in tying up a large portion
of system resources, while encrypting pages of zeros, with no way for
the truncate operation to be stopped from userspace.
This patch adds the ability for ecryptfs_write() to detect a pending
fatal signal and return as gracefully as possible. The intent is to
leave the lower file in a useable state, while still allowing a user to
break out of the encryption loop. If a pending fatal signal is detected,
the eCryptfs inode size is updated to reflect the modified inode size
and then -EINTR is returned.
Signed-off-by: Tyler Hicks <[email protected]>
Cc: <[email protected]>
|
|
ecryptfs_write() can enter an infinite loop when truncating a file to a
size larger than 4G. This only happens on architectures where size_t is
represented by 32 bits.
This was caused by a size_t overflow due to it incorrectly being used to
store the result of a calculation which uses potentially large values of
type loff_t.
[[email protected]: rewrite subject and commit message]
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Yunchuan Wen <[email protected]>
Reviewed-by: Cong Wang <[email protected]>
Cc: <[email protected]>
Signed-off-by: Tyler Hicks <[email protected]>
|
|
ecryptfs_miscdev_read() and ecryptfs_miscdev_write() contained many
magic numbers for specifying packet header field sizes and offsets. This
patch defines those values and replaces the magic values.
Signed-off-by: Tyler Hicks <[email protected]>
|
|
Errors in writes to /dev/ecryptfs were being incorrectly reported by
returning 0 or the value of the original write count.
This patch clears up the return code assignment in error paths.
Signed-off-by: Tyler Hicks <[email protected]>
|
|
A malicious count value specified when writing to /dev/ecryptfs may
result in a a very large kernel memory allocation.
This patch peeks at the specified packet payload size, adds that to the
size of the packet headers and compares the result with the write count
value. The resulting maximum memory allocation size is approximately 532
bytes.
Signed-off-by: Tyler Hicks <[email protected]>
Reported-by: Sasha Levin <[email protected]>
Cc: <[email protected]>
|
|
Removes unneeded variable initialization in ecryptfs_read_metadata(). Also adds
a small comment to help explain metadata reading logic.
[[email protected]: Pulled out of for-stable patch and wrote commit msg]
Signed-off-by: Tim Gardner <[email protected]>
Signed-off-by: Tyler Hicks <[email protected]>
|
|
Print inode on metadata read failure. The only real
way of dealing with metadata read failures is to delete
the underlying file system file. Having the inode
allows one to 'find . -inum INODE`.
[[email protected]: Removed some minor not-for-stable parts]
Signed-off-by: Tim Gardner <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Cc: [email protected]
Signed-off-by: Tyler Hicks <[email protected]>
|
|
Update my email address in MAINTAINERS.
Signed-off-by: Dustin Kirkland <[email protected]>
Signed-off-by: Tyler Hicks <[email protected]>
|
|
Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
regressions in the nouveau driver.
move_notify() was originally able to presume that bo->mem is the old node,
and new_mem is the new node. The above commit moves the call to
move_notify() to after move() has been done, which means that now, sometimes,
new_mem isn't the new node at all, bo->mem is, and new_mem points at a
stale, possibly-just-been-killed-by-move node.
This is clearly not a good situation. This patch reverts this change, and
replaces it with a cleanup in the move() failure path instead.
The second issue is that the call to move_notify() from cleanup_memtype_use()
causes the TTM ghost objects to get passed into the driver. This is clearly
bad as the driver knows nothing about these "fake" TTM BOs, and ends up
accessing uninitialised memory.
I worked around this in nouveau's move_notify() hook by ensuring the BO
destructor was nouveau's. I don't particularly like this solution, and
would rather TTM never pass the driver these objects. However, I don't
clearly understand the reason why we're calling move_notify() here anyway
and am happy to work around the problem in nouveau instead of breaking the
behaviour expected by other drivers.
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Thomas Hellstrom <[email protected]>
Cc: Jerome Glisse <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
We need to write the configuration for each microphone to a different
register.
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
|
|
My forcewake spinlock patches have a functional conflict with Ben
Widawsky's gen6 drpc support for debugfs. Result was a benign warning
about trying to read an non-atomic variabla with atomic_read.
Note that the entire check is racy anyway and purely informational.
Also update it to reflect the forcewake voodoo changes, the kernel can
now also hold onto a forcewake reference for longer times.
Signed-Off-by: Daniel Vetter <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
Signed-off-by: Keith Packard <[email protected]>
|
|
Commit b52a360b forgot to call xfs_iunlock() when it detected corrupted
symplink and bailed out. Fix it by jumping to 'out' instead of doing return.
CC: [email protected]
CC: Carlos Maiolino <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
Reviewed-by: Dave Chinner <[email protected]>
Signed-off-by: Ben Myers <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
* 'for-greg' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb:
usb: musb: omap2430: minor cleanups.
usb: dwc3: unmap the proper number of sg entries
usb: musb: fix shutdown while usb gadget is in use
usb: gadget: f_mass_storage: Use "bool" instead of "int" in fsg_module_parameters
usb: gadget: check for streams only for SS udcs
usb: gadget: fsl_udc: fix the usage of udc->max_ep
drivers: usb: otg: Fix dependencies for some OTG drivers
usb: renesas: silence uninitialized variable report in usbhsg_recip_run_handle()
usb: gadget: SS Isoc endpoints use comp_desc->bMaxBurst too
usb: gadget: storage: endian fix
usb: dwc3: ep0: fix compile warning
usb: musb: davinci: fix build breakage
usb: gadget: langwell: don't call gadget's disconnect()
usb: gadget: langwell: drop langwell_otg support
usb: otg: kill langwell_otg driver
usb: dwc3: ep0: tidy up Pending Request handling
|
|
When we have identified an accessory make sure we've flagged that we've
done so in order to make sure we always report buttons and don't continue
to polarity flip.
Signed-off-by: Mark Brown <[email protected]>
|