- 23 Sep, 2010 1 commit
-
-
Eric Dumazet authored
rcu_dereference_bh() doesnt know yet about hard irq being disabled, so lockdep can trigger in netpoll_rx() after commit f0f9deae (netpoll: Disable IRQ around RCU dereference in netpoll_rx) Reported-by:
Miles Lane <miles.lane@gmail.com> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Tested-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com>
-
- 10 Sep, 2010 39 commits
-
-
Heiko Carstens authored
Just got my 6 way machine to a state where cpu 0 is in an endless loop within __smp_call_function_single. All other cpus are idle. The call trace on cpu 0 looks like this: __smp_call_function_single scheduler_tick update_process_times tick_sched_timer __run_hrtimer hrtimer_interrupt clock_comparator_work do_extint ext_int_handler ----> timer irq cpu_idle __smp_call_function_single() got called from nohz_balancer_kick() (inlined) with the remote cpu being 1, wait being 0 and the per cpu variable remote_sched_softirq_cb (call_single_data) of the current cpu (0). Then it loops forever when it tries to grab the lock of the call_single_data, since it is already locked and enqueued on cpu 0. My theory how this could have happened: for some reason the scheduler decided to call __smp_call_function_single() on it's own cpu, and sends an IPI to itself. The interrupt stays pending since IRQs are disabled. If then the hypervisor schedules the cpu away it might happen that upon rescheduling both the IPI and the timer IRQ are pending. If then interrupts are enabled again it depends which one gets scheduled first. If the timer interrupt gets delivered first we end up with the local deadlock as seen in the calltrace above. Let's make __smp_call_function_single() check if the target cpu is the current cpu and execute the function immediately just like smp_call_function_single does. That should prevent at least the scenario described here. It might also be that the scheduler is not supposed to call __smp_call_function_single with the remote cpu being the current cpu, but that is a different issue. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Jens Axboe <jaxboe@fusionio.com> Cc: Venkatesh Pallipadi <venki@google.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <20100910114729.GB2827@osiris.boeblingen.de.ibm.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-devLinus Torvalds authored
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: libata-sff: Reenable Port Multiplier after libata-sff remodeling. libata: skip EH autopsy and recovery during suspend ahci: AHCI and RAID mode SATA patch for Intel Patsburg DeviceIDs ata_piix: IDE Mode SATA patch for Intel Patsburg DeviceIDs libata,pata_via: revert ata_wait_idle() removal from ata_sff/via_tf_load() ahci: fix hang on failed softreset pata_artop: Fix device ID parity check
-
Gwendal Grignou authored
Keep track of the link on the which the current request is in progress. It allows support of links behind port multiplier. Not all libata-sff is PMP compliant. Code for native BMDMA controller does not take in accound PMP. Tested on Marvell 7042 and Sil7526. Signed-off-by:
Gwendal Grignou <gwendal@google.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Tejun Heo authored
For some mysterious reason, certain hardware reacts badly to usual EH actions while the system is going for suspend. As the devices won't be needed until the system is resumed, ask EH to skip usual autopsy and recovery and proceed directly to suspend. Signed-off-by:
Tejun Heo <tj@kernel.org> Tested-by:
Stephan Diestelhorst <stephan.diestelhorst@amd.com> Cc: stable@kernel.org Signed-off-by:
-
Seth Heasley authored
This patch adds the Intel Patsburg (PCH) SATA AHCI and RAID Controller DeviceIDs. Signed-off-by:
Seth Heasley <seth.heasley@intel.com> Signed-off-by:
-
Seth Heasley authored
This patch adds the Intel Patsburg (PCH) IDE mode SATA Controller DeviceIDs. Signed-off-by:
-
Tejun Heo authored
Commit 978c0666 (libata: Remove excess delay in the tf_load path) removed ata_wait_idle() from ata_sff_tf_load() and via_tf_load(). This caused obscure detection problems in sata_sil. https://bugzilla.kernel.org/show_bug.cgi?id=16606 The commit was pure performance optimization. Revert it for now. Reported-by:
Dieter Plaetinck <dieter@plaetinck.be> Reported-by:
Jan Beulich <JBeulich@novell.com> Bisected-by:
gianluca <gianluca@sottospazio.it> Cc: stable@kernel.org Signed-off-by:
-
Jorge Boncompte [DTI2] authored
Commit 9eed1fb7 ("minix: replace inode uid,gid,mode init with helper") broke directory creation on minix filesystems. Fix it by passing the needed mode flag to inode init helper. Signed-off-by:
Jorge Boncompte [DTI2] <jorge@dti2.net> Cc: Dmitry Monakhov <dmonakhov@openvz.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: <stable@kernel.org> [2.6.35.x] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Mel Gorman authored
When under significant memory pressure, a process enters direct reclaim and immediately afterwards tries to allocate a page. If it fails and no further progress is made, it's possible the system will go OOM. However, on systems with large amounts of memory, it's possible that a significant number of pages are on per-cpu lists and inaccessible to the calling process. This leads to a process entering direct reclaim more often than it should increasing the pressure on the system and compounding the problem. This patch notes that if direct reclaim is making progress but allocations are still failing that the system is already under heavy pressure. In this case, it drains the per-cpu lists and tries the allocation a second time before continuing. Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Reviewed-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Reviewed-by:
Christoph Lameter <cl@linux.com> Cc: Dave Chinner <david@fromorbit.com> Cc: Wu Fengguang <fengguang.wu@intel.com> Cc: David Rientjes <rientjes@google.com> Signed-off-by:
-
Christoph Lameter authored
mm: page allocator: calculate a better estimate of NR_FREE_PAGES when memory is low and kswapd is awake Ordinarily watermark checks are based on the vmstat NR_FREE_PAGES as it is cheaper than scanning a number of lists. To avoid synchronization overhead, counter deltas are maintained on a per-cpu basis and drained both periodically and when the delta is above a threshold. On large CPU systems, the difference between the estimated and real value of NR_FREE_PAGES can be very high. If NR_FREE_PAGES is much higher than number of real free page in buddy, the VM can allocate pages below min watermark, at worst reducing the real number of pages to zero. Even if the OOM killer kills some victim for freeing memory, it may not free memory if the exit path requires a new page resulting in livelock. This patch introduces a zone_page_state_snapshot() function (courtesy of Christoph) that takes a slightly more accurate view of an arbitrary vmstat counter. It is used to read NR_FREE_PAGES while kswapd is awake to avoid the watermark being accidentally broken. The estimate is not perfect and may result in cache line bounces but is expected to be lighter than the IPI calls necessary to continually drain the per-cpu counters while kswapd is awake. Signed-off-by:
-
Mel Gorman authored
When allocating a page, the system uses NR_FREE_PAGES counters to determine if watermarks would remain intact after the allocation was made. This check is made without interrupts disabled or the zone lock held and so is race-prone by nature. Unfortunately, when pages are being freed in batch, the counters are updated before the pages are added on the list. During this window, the counters are misleading as the pages do not exist yet. When under significant pressure on systems with large numbers of CPUs, it's possible for processes to make progress even though they should have been stalled. This is particularly problematic if a number of the processes are using GFP_ATOMIC as the min watermark can be accidentally breached and in extreme cases, the system can livelock. This patch updates the counters after the pages have been added to the list. This makes the allocator more cautious with respect to preserving the watermarks and mitigates livelock possibilities. [akpm@linux-foundation.org: avoid modifying incoming args] Signed-off-by:
Rik van Riel <riel@redhat.com> Reviewed-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
refresh_zone_stat_thresholds() calculates parameter based on the number of online cpus. It's called at cpu offlining but needs to be called at onlining, too. Signed-off-by:
-
James Bottomley authored
O_NONBLOCK on parisc has a dual value: #define O_NONBLOCK 000200004 /* HPUX has separate NDELAY & NONBLOCK */ It is caught by the O_* bits uniqueness check and leads to a parisc compile error. The fix would be to take O_NONBLOCK out. Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Cc: Jamie Lokier <jamie@shareable.org> Signed-off-by:
-
Hugh Dickins authored
Tests with recent firmware on Intel X25-M 80GB and OCZ Vertex 60GB SSDs show a shift since I last tested in December: in part because of firmware updates, in part because of the necessary move from barriers to awaiting completion at the block layer. While discard at swapon still shows as slightly beneficial on both, discarding 1MB swap cluster when allocating is now disadvanteous: adds 25% overhead on Intel, adds 230% on OCZ (YMMV). Surrender: discard as presently implemented is more hindrance than help for swap; but might prove useful on other devices, or with improvements. So continue to do the discard at swapon, but make discard while swapping conditional on a SWAP_FLAG_DISCARD to sys_swapon() (which has been using only the lower 16 bits of int flags). We can add a --discard or -d to swapon(8), and a "discard" to swap in /etc/fstab: matching the mount option for btrfs, ext4, fat, gfs2, nilfs2. Signed-off-by:
Hugh Dickins <hughd@google.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Nigel Cunningham <nigel@tuxonice.net> Cc: Tejun Heo <tj@kernel.org> Cc: Jens Axboe <jaxboe@fusionio.com> Cc: James Bottomley <James.Bottomley@hansenpartnership.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: <stable@kernel.org> Signed-off-by:
-
Christoph Hellwig authored
The swap code already uses synchronous discards, no need to add I/O barriers. This fixes the worst of the terrible slowdown in swap allocation for hibernation, reported on 2.6.35 by Nigel Cunningham; but does not entirely eliminate that regression. [tj@kernel.org: superflous newlines removed] Signed-off-by:
Christoph Hellwig <hch@lst.de> Tested-by:
Nigel Cunningham <nigel@tuxonice.net> Signed-off-by:
-
Hugh Dickins authored
Move the hibernation check from scan_swap_map() into try_to_free_swap(): to catch not only the common case when hibernation's allocation itself triggers swap reuse, but also the less likely case when concurrent page reclaim (shrink_page_list) might happen to try_to_free_swap from a page. Hibernation already clears __GFP_IO from the gfp_allowed_mask, to stop reclaim from going to swap: check that to prevent swap reuse too. Signed-off-by:
-
Hugh Dickins authored
Please revert 2.6.36-rc commit d2997b10 "hibernation: freeze swap at hibernation". It complicated matters by adding a second swap allocation path, just for hibernation; without in any way fixing the issue that it was intended to address - page reclaim after fixing the hibernation image might free swap from a page already imaged as swapcache, letting its swap be reallocated to store a different page of the image: resulting in data corruption if the imaged page were freed as clean then swapped back in. Pages freed to si->swap_map were still in danger of being reallocated by the alternative allocation path. I guess it inadvertently fixed slow SSD swap allocation for hibernation, as reported by Nigel Cunningham: by missing out the discards that occur on the usual swap allocation path; but that was unintentional, and needs a separate fix. Signed-off-by:
-
Gary King authored
I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform cache maintenance lazily), and the root cause appears to be that the mm bouncing code is calling flush_dcache_page before it copies the bounce buffer into the bio. The bounced page needs to be flushed after data is copied into it, to ensure that architecture implementations can synchronize instruction and data caches if necessary. Signed-off-by:
Gary King <gking@nvidia.com> Cc: Tejun Heo <tj@kernel.org> Cc: Russell King <rmk@arm.linux.org.uk> Acked-by:
Jens Axboe <axboe@kernel.dk> Cc: <stable@kernel.org> Signed-off-by:
-
Linus Walleij authored
It was a mistake to mark the PL031 IRQ as shared (for the U8500), we misread the datasheet. Get rid of this. Signed-off-by:
Linus Walleij <linus.walleij@stericsson.com> Cc: Jonas Aberg <jonas.aberg@stericsson.com> Cc: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com> Acked-by:
Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Wolfram Sang authored
Because no one dared to remove it so far, let's keep the entry correct, at least. Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Acked-by:
Mike Frysinger <vapier@gentoo.org> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
David Brownell authored
There's been some recent confusion about error checking GPIO numbers. briefly, it should be handled mostly during setup, when gpio_request() is called, and NEVER by expectig gpio_is_valid to report more than never-usable GPIO numbers. [akpm@linux-foundation.org: terminate unterminated comment] Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Cc: Eric Miao" <eric.y.miao@gmail.com> Cc: "Ryan Mallon" <ryan@bluewatersys.com> Signed-off-by:
-
Gregory Bean authored
Replace the arbitrary software-reset call from the device-probe method, because: - It is defective. To work correctly, it should be two byte writes, not a single word write. As it stands, it does nothing. - Some devices with sx150x expanders installed have their NRESET pins ganged on the same line, so resetting one causes the others to reset - not a nice thing to do arbitrarily! - The probe, usually taking place at boot, implies a recent hard-reset, so a software reset at this point is just a waste of energy anyway. Therefore, make it optional, defaulting to off, as this will match the common case of probing at powerup and also matches the current broken no-op behavior. Signed-off-by:
Gregory Bean <gbean@codeaurora.org> Reviewed-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
next_active_pageblock() is for finding next _used_ freeblock. It skips several blocks when it finds there are a chunk of free pages lager than pageblock. But it has 2 bugs. 1. We have no lock. page_order(page) - pageblock_order can be minus. 2. pageblocks_stride += is wrong. it should skip page_order(p) of pages. Signed-off-by:
-
Minchan Kim authored
Iram reported that compaction's too_many_isolated() loops forever. (http://www.spinics.net/lists/linux-mm/msg08123.html) The meminfo when the situation happened was inactive anon is zero. That's because the system has no memory pressure until then. While all anon pages were in the active lru, compaction could select active lru as well as inactive lru. That's a different thing from vmscan's isolated. So we has been two too_many_isolated. While compaction can isolate pages in both active and inactive, current implementation of too_many_isolated only considers inactive. It made Iram's problem. This patch handles active and inactive fairly. That's because we can't expect where from and how many compaction would isolated pages. This patch changes (nr_isolated > nr_inactive) with nr_isolated > (nr_active + nr_inactive) / 2. Signed-off-by:
Iram Shahzad <iram.shahzad@jp.fujitsu.com> Acked-by:
-
Jerome Marchand authored
gid_t is a unsigned int. If group_info contains a gid greater than MAX_INT, groups_search() function may look on the wrong side of the search tree. This solves some unfair "permission denied" problems. Signed-off-by:
Jerome Marchand <jmarchan@redhat.com> Cc: <stable@kernel.org> Signed-off-by:
-
Ira W. Snyder authored
The slab.h header is required to use the kmalloc() family of functions. Due to recent kernel changes, this header must be directly included by code that calls into the memory allocator. Without this patch, any code which includes this header fails to build. Signed-off-by:
Ira W. Snyder <iws@ovro.caltech.edu> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Atsushi Nemoto authored
Commit b485fe5e ("rtc/m41t80: use rtc_valid_tm() to check returned tm") added rtc_valid_tm to m41t80_rtc_read_alarm() but it was wrong while the t->time does not contain complete date/time. This patch also fixes a warning: warning: passing argument 1 of 'rtc_valid_tm' from incompatible pointer type Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Wan ZongShun <mcuos.com@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Jan Sembera authored
Commit 74641f58 ("alpha: binfmt_aout fix") (May 2009) introduced a regression - binfmt_misc is now consulted after binfmt_elf, which will unfortunately break ia32el. ia32 ELF binaries on ia64 used to be matched using binfmt_misc and executed using wrapper. As 32bit binaries are now matched by binfmt_elf before bindmt_misc kicks in, the wrapper is ignored. The fix increases precedence of binfmt_misc to the original state. Signed-off-by:
Jan Sembera <jsembera@suse.cz> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Richard Henderson <rth@twiddle.net Cc: <stable@kernel.org> [2.6.everything.x] Signed-off-by:
-
Andrea Arcangeli authored
COMPACTION enables MIGRATION, but MIGRATION spawns a warning if numa or memhotplug aren't selected. However MIGRATION doesn't depend on them. I guess it's just trying to be strict doing a double check on who's enabling it, but it doesn't know that compaction also enables MIGRATION. Signed-off-by:
Andrea Arcangeli <aarcange@redhat.com> Acked-by:
-
Andrea Arcangeli authored
The pte_same check is reliable only if the swap entry remains pinned (by the page lock on swapcache). We've also to ensure the swapcache isn't removed before we take the lock as try_to_free_swap won't care about the page pin. One of the possible impacts of this patch is that a KSM-shared page can point to the anon_vma of another process, which could exit before the page is freed. This can leave a page with a pointer to a recycled anon_vma object, or worse, a pointer to something that is no longer an anon_vma. [riel@redhat.com: changelog help] Signed-off-by:
-
Julia Lawall authored
Move the second if (reg & ...) test into the branch indicated by its indentation. The test was previously always executed after the if containing that branch, but it was always false unless the if branch was taken. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r disable braces4@ position p1,p2; statement S1,S2; @@ ( if (...) { ... } | if (...) S1@p1 S2@p2 ) @script:python@ p1 << r.p1; p2 << r.p2; @@ if (p1[0].column == p2[0].column): cocci.print_main("branch",p1) cocci.print_secs("after",p2) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
Chris Ball <cjb@laptop.org> Cc: Pavel Pisa <ppisa@pikron.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
-
Ethan Du authored
If suspend called when kmmcd is doing host->ops->disable, as kmmcd already increased host->en_dis_recurs to 1, the mmc_host_enable in suspend function will return directly without increase the nesting_cnt, which will cause the followed register access carried out to the disabled host. mmc_suspend_host will enable host itself. No need to enable host before it. Also works on kmmcd will get flushed in mmc_suspend_host, enable host after it will be safe. So make the mmc_host_enable after it. [cjb: rebase against current Linus] Signed-off-by:
Ethan <ethan.too@gmail.com> Signed-off-by:
Adrian Hunter <adrian.hunter@nokia.com> Acked-by:
Madhusudhan Chikkature <madhu.cr@ti.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
-
Marc Kleine-Budde authored
Fix the following error: at91_mci.c: In function 'at91_mci_sg_to_dma': at91_mci.c:236: error: implicit declaration of function 'kmap_atomic' at91_mci.c:236: error: 'KM_BIO_SRC_IRQ' undeclared (first use in this function) at91_mci.c:236: error: (Each undeclared identifier is reported only once at91_mci.c:236: error: for each function it appears in.) at91_mci.c:236: warning: assignment makes pointer from integer without a cast at91_mci.c:252: error: implicit declaration of function 'kunmap_atomic' at91_mci.c: In function 'at91_mci_post_dma_read': at91_mci.c:302: error: 'KM_BIO_SRC_IRQ' undeclared (first use in this function) at91_mci.c:302: warning: assignment makes pointer from integer without a cast at91_mci.c:317: error: implicit declaration of function 'flush_kernel_dcache_page' Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Sergio Aguirre authored
This fixes the following warning: drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend': drivers/mmc/host/omap_hsmmc.c:2275: warning: unused variable 'state' Introduced by commit ID: commit 1a13f8fa Author: Matt Fleming <matt@console-pimps.org> Date: Wed May 26 14:42:08 2010 -0700 mmc: remove the "state" argument to mmc_suspend_host() The unique usage of this var was removed there, and missed removing the respective declaration aswell. Signed-off-by:
Sergio Aguirre <saaguirre@ti.com> Signed-off-by:
Matt Fleming <matt@console-pimps.org> Cc: Madhusudhan Chikkature <madhu.cr@ti.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
-
Jiri Pinkava authored
[cjb: fix line-wrapped patch] Signed-off-by:
Jiri Pinkava <jiri.pinkava@vscht.cz> Signed-off-by:
-
Guennadi Liakhovetski authored
kunmap_atomic() takes the cookie, returned by the kmap_atomic() as its argument and not the page address, used as an argument to kmap_atomic(). This patch fixes the compile error: In file included from drivers/mmc/host/tmio_mmc.c:37: drivers/mmc/host/tmio_mmc.h: In function 'tmio_mmc_kunmap_atomic': drivers/mmc/host/tmio_mmc.h:192: error: negative width in bit-field '<anonymous>' Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by:
Eric Miao <eric.y.miao@gmail.com> Tested-by:
Magnus Damm <damm@opensource.se> Cc: <stable@kernel.org> Signed-off-by:
-
Yusuke Goda authored
Previously, it was possible for ack_mmc_irqs() to clear pending interrupt bits in the CTL_STATUS register, even though the interrupt handler had not been called. This was because of a race that existed when doing a read-modify-write sequence on CTL_STATUS. After the read step in this sequence, if an interrupt occurred (causing one of the bits in CTL_STATUS to be set) the write step would inadvertently clear it. Observed with the TMIO_STAT_RXRDY bit together with CMD53 on AR6002 and BCM4318 SDIO cards in polled mode. This patch eliminates this race by only writing to CTL_STATUS and clearing the interrupts that were passed as an argument to ack_mmc_irqs()." [matt@console-pimps.org: rewrote changelog] Signed-off-by:
Yusuke Goda <yusuke.goda.sx@renesas.com> Acked-by: Magnus Damm <damm@opensource.se>" Tested-by: Arnd Hannemann <arnd@arndnet.de>" Acked-by:
Ian Molton <ian@mnementh.co.uk> Cc: Matt Fleming <matt@console-pimps.org> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: <linux-mmc@vger.kernel.org> Cc: <stable@kernel.org> Signed-off-by:
-
Michael S. Tsirkin authored
Add cgroup_attach_task_all() The existing cgroup_attach_task_current_cg() API is called by a thread to attach another thread to all of its cgroups; this is unsuitable for cases where a privileged task wants to attach itself to the cgroups of a less privileged one, since the call must be made from the context of the target task. This patch adds a more generic cgroup_attach_task_all() API that allows both the source task and to-be-moved task to be specified. cgroup_attach_task_current_cg() becomes a specialization of the more generic new function. [menage@google.com: rewrote changelog] [akpm@linux-foundation.org: address reviewer comments] Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Tested-by:
Alex Williamson <alex.williamson@redhat.com> Acked-by:
Paul Menage <menage@google.com> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Ben Blum <bblum@google.com> Cc: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by:
-
Takashi Iwai authored
Fix the left-over old ifdef for PG_uncached in /proc/kpageflags. Now it's used by x86, too. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
-
![Jorge Boncompte [DTI2]'s avatar](https://secure.gravatar.com/avatar/5c0cf83a6a7ce7bbeef63cef2c3f4163?s=80&d=identicon "Jorge Boncompte [DTI2]")
