* Linux 3.18.55
From: Greg KH @ 2017-05-25 16:18 UTC (permalink / raw)
To: linux-kernel, Andrew Morton, torvalds, stable; +Cc: lwn, Jiri Slaby
[-- Attachment #1: Type: text/plain, Size: 8432 bytes --]
I'm announcing the release of the 3.18.55 kernel.
All users of the 3.18 kernel series must upgrade.
The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/arm64/tagged-pointers.txt | 62 +++++++++++++----
Makefile | 2
arch/alpha/kernel/osf_sys.c | 6 +
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 5 -
arch/arm64/include/asm/uaccess.h | 3
arch/metag/include/asm/uaccess.h | 49 ++++++++-----
arch/powerpc/platforms/pseries/dlpar.c | 1
drivers/char/lp.c | 6 +
drivers/char/mem.c | 5 +
drivers/iio/dac/ad7303.c | 6 -
drivers/iio/proximity/as3935.c | 3
drivers/md/dm-bufio.c | 9 +-
drivers/md/dm-thin-metadata.c | 4 -
drivers/md/persistent-data/dm-btree.c | 8 +-
drivers/md/persistent-data/dm-space-map-disk.c | 15 +++-
drivers/media/platform/s5p-mfc/s5p_mfc.c | 1
drivers/media/rc/mceusb.c | 4 -
drivers/media/tuners/tuner-xc2028.c | 37 ++++------
drivers/media/usb/cx231xx/cx231xx-audio.c | 15 +++-
drivers/media/usb/cx231xx/cx231xx-cards.c | 45 +++++++++++-
drivers/media/usb/dvb-usb/dib0700_core.c | 3
drivers/media/usb/dvb-usb/ttusb2.c | 19 +++++
drivers/media/usb/gspca/konica.c | 3
drivers/media/usb/usbvision/usbvision-video.c | 9 ++
drivers/media/usb/zr364xx/zr364xx.c | 8 ++
drivers/net/irda/irda-usb.c | 2
drivers/net/wireless/ath/ath9k/hif_usb.c | 3
drivers/net/wireless/mwifiex/pcie.c | 7 +
drivers/of/address.c | 2
drivers/of/fdt.c | 3
drivers/pci/pci-sysfs.c | 10 +-
drivers/pci/pci.c | 9 +-
drivers/regulator/tps65023-regulator.c | 3
drivers/tty/tty_ldisc.c | 7 +
drivers/usb/class/cdc-acm.c | 13 ++-
drivers/usb/core/devio.c | 4 -
drivers/usb/core/hcd.c | 4 -
drivers/usb/core/hub.c | 19 +++--
drivers/usb/core/urb.c | 2
drivers/usb/host/xhci-mem.c | 2
drivers/usb/host/xhci-plat.c | 2
drivers/usb/misc/iowarrior.c | 2
drivers/usb/misc/legousbtower.c | 1
drivers/usb/musb/tusb6010_omap.c | 13 ++-
drivers/usb/serial/ftdi_sio.c | 10 +-
drivers/usb/serial/ftdi_sio_ids.h | 2
drivers/usb/serial/io_ti.c | 5 +
drivers/usb/serial/mct_u232.c | 2
drivers/usb/serial/option.c | 8 ++
drivers/usb/serial/qcserial.c | 2
drivers/usb/storage/ene_ub6250.c | 90 +++++++++++++++----------
drivers/uwb/i1480/dfu/usb.c | 5 -
drivers/watchdog/pcwd_usb.c | 3
include/linux/kprobes.h | 4 -
kernel/fork.c | 2
kernel/kprobes.c | 2
kernel/pid_namespace.c | 2
kernel/trace/trace_kprobe.c | 5 +
mm/huge_memory.c | 12 +++
net/ipx/af_ipx.c | 5 -
security/integrity/ima/ima_appraise.c | 5 -
61 files changed, 427 insertions(+), 173 deletions(-)
Al Viro (1):
osf_wait4(): fix infoleak
Alan Stern (1):
USB: ene_usb6250: fix DMA to the stack
Alyssa Milburn (2):
ttusb2: limit messages to buffer size
zr364xx: enforce minimum size when reading header
Andrey Korolyov (1):
USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
Anthony Mallet (1):
USB: serial: ftdi_sio: fix setting latency for unprivileged users
Bjørn Mork (1):
USB: serial: qcserial: add more Lenovo EM74xx device IDs
Brian Norris (1):
mwifiex: pcie: fix cmd_buf use-after-free in remove/reset
Dan Carpenter (1):
ipx: call ipxitf_put() in ioctl error path
Daniel Glöckner (1):
ima: accept previously set IMA_NEW_FILE
Daniel Micay (1):
stackprotector: Increase the per-task stack canary's random range from 32 bits to 64 bits on 64-bit platforms
Daniele Palmas (1):
usb: serial: option: add Telit ME910 support
David Woodhouse (1):
PCI: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms
Eric W. Biederman (1):
pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
Greg Kroah-Hartman (1):
Linux 3.18.55
James Hogan (2):
metag/uaccess: Fix access_ok()
metag/uaccess: Check access_ok in strncpy_from_user
Joe Thornber (2):
dm thin metadata: call precommit before saving the roots
dm space map disk: fix some book keeping in the disk space map
Johan Hovold (16):
watchdog: pcwd_usb: fix NULL-deref at probe
ath9k_htc: fix NULL-deref at probe
of: fdt: add missing allocation-failure check
net: irda: irda-usb: fix firmware name on big-endian hosts
usbvision: fix NULL-deref at probe
mceusb: fix NULL-deref at probe
USB: iowarrior: fix info ioctl on big-endian hosts
USB: serial: mct_u232: fix big-endian baud-rate handling
USB: serial: io_ti: fix div-by-zero in set_termios
USB: hub: fix SS hub-descriptor handling
USB: hub: fix non-SS hub-descriptor handling
gspca: konica: add missing endpoint sanity check
dib0700: fix NULL-deref at probe
cx231xx-cards: fix NULL-deref at probe
cx231xx-audio: fix NULL-deref at probe
uwb: fix device quirk on big-endian hosts
Julius Werner (1):
drivers: char: mem: Check for address space wraparound with mmap()
Keno Fischer (1):
mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp
Kristina Martsenko (1):
arm64: documentation: document tagged pointer stack constraints
Ludovic Desroches (2):
ARM: dts: at91: sama5d3_xplained: fix ADC vref
ARM: dts: at91: sama5d3_xplained: not all ADC channels are available
Lukas Wunner (1):
PCI: Freeze PME scan before suspending devices
Maksim Salau (1):
usb: misc: legousbtower: Fix memory leak
Marek Szyprowski (1):
s5p-mfc: Fix unbalanced call to clock management
Mark Rutland (1):
arm64: uaccess: ensure extension of access_ok() addr
Matt Ranostay (1):
iio: proximity: as3935: fix as3935_write
Mikulas Patocka (1):
dm bufio: avoid a possible ABBA deadlock
Pavel Roskin (1):
iio: dac: ad7303: fix channel description
Peter Chen (1):
usb: host: xhci-mem: allocate zeroed Scratchpad Buffer
Peter Hurley (1):
tty: Prevent ldisc drivers from re-using stale tty fields
Peter Ujfalusi (1):
usb: musb: tusb6010_omap: Do not reset the other direction's packet size
Richard Cochran (1):
regulator: tps65023: Fix inverted core enable logic.
Rob Herring (1):
of: fix sparse warning in of_pci_range_parser_one
Takashi Iwai (1):
xc2028: Fix use-after-free bug properly
Thomas Gleixner (1):
tracing/kprobes: Enforce kprobes teardown after testing
Thomas Petazzoni (1):
usb: host: xhci-plat: propagate return value of platform_get_irq()
Tobias Herzog (1):
cdc-acm: fix possible invalid access when processing notification
Tyrel Datwyler (1):
powerpc/pseries: Fix of_node_put() underflow during DLPAR remove
Vamsi Krishna Samavedam (1):
USB: core: replace %p with %pK
Vinothkumar Raja (1):
dm btree: fix for dm_btree_find_lowest_key()
Willy Tarreau (1):
char: lp: fix possible integer overflow in lp_setup()
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* linux-3.18.y build: 0 failures 0 warnings (v3.18.54-60-g6b65a8f)
From: Build bot for Mark Brown @ 2017-05-25 16:14 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, stable
Tree/Branch: linux-3.18.y
Git describe: v3.18.54-60-g6b65a8f
Commit: 6b65a8f64f Linux 3.18.55
Build Time: 61 min 12 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 0
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
-------------------------------------------------------------------------------
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm64-allmodconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
^ permalink raw reply
* Re: [PATCH rdma-next] IB/iser: Fix connection teardown race condition
From: Max Gurtovoy @ 2017-05-25 15:24 UTC (permalink / raw)
To: Leon Romanovsky, Doug Ledford; +Cc: linux-rdma, Vladimir Neyelov, stable, sagig
In-Reply-To: <20170521161731.22223-1-leon@kernel.org>
Hi Sagi,
what do you think on this approach ?
we must somehow defend on the NULL deref in case dd_data in iscsi_conn
(the iser_conn) already NULL due to conn_stop call.
>
> diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c b/drivers/infiniband/ulp/iser/iscsi_iser.c
> index 5a887efb4bdf..9ba649836d86 100644
> --- a/drivers/infiniband/ulp/iser/iscsi_iser.c
> +++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
> @@ -83,6 +83,7 @@ static struct scsi_host_template iscsi_iser_sht;
> static struct iscsi_transport iscsi_iser_transport;
> static struct scsi_transport_template *iscsi_iser_scsi_transport;
> static struct workqueue_struct *release_wq;
> +static DEFINE_MUTEX(unbind_iser_conn_mutex);
> struct iser_global ig;
>
> int iser_debug_level = 0;
> @@ -550,12 +551,14 @@ iscsi_iser_conn_stop(struct iscsi_cls_conn *cls_conn, int flag)
> */
> if (iser_conn) {
> mutex_lock(&iser_conn->state_mutex);
> + mutex_lock(&unbind_iser_conn_mutex);
> iser_conn_terminate(iser_conn);
> iscsi_conn_stop(cls_conn, flag);
>
> /* unbind */
> iser_conn->iscsi_conn = NULL;
> conn->dd_data = NULL;
> + mutex_unlock(&unbind_iser_conn_mutex);
>
> complete(&iser_conn->stop_completion);
> mutex_unlock(&iser_conn->state_mutex);
> @@ -977,13 +980,21 @@ static int iscsi_iser_slave_alloc(struct scsi_device *sdev)
> struct iser_conn *iser_conn;
> struct ib_device *ib_dev;
>
> + mutex_lock(&unbind_iser_conn_mutex);
> +
> session = starget_to_session(scsi_target(sdev))->dd_data;
> iser_conn = session->leadconn->dd_data;
> + if (!iser_conn) {
> + mutex_unlock(&unbind_iser_conn_mutex);
> + return -ENOTCONN;
> + }
> ib_dev = iser_conn->ib_conn.device->ib_device;
>
> if (!(ib_dev->attrs.device_cap_flags & IB_DEVICE_SG_GAPS_REG))
> blk_queue_virt_boundary(sdev->request_queue, ~MASK_4K);
>
> + mutex_unlock(&unbind_iser_conn_mutex);
> +
> return 0;
> }
>
> --
> 2.12.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] ext4: Fix fdatasync(2) after extent manipulation operations
From: Jan Kara @ 2017-05-25 14:25 UTC (permalink / raw)
To: Ted Tso; +Cc: linux-ext4, Jan Kara, stable
Currently, extent manipulation operations such as hole punch, range
zeroing, or extent shifting do not record the fact that file data has
changed and thus fdatasync(2) has a work to do. As a result if we crash
e.g. after a punch hole and fdatasync, user can still possibly see the
punched out data after journal replay. Test generic/392 fails due to
these problems.
Fix the problem by properly marking that file data has changed in these
operations.
CC: stable@vger.kernel.org
Fixes: a4bb6b64e39abc0e41ca077725f2a72c868e7622
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext4/extents.c | 5 +++++
fs/ext4/inode.c | 2 ++
2 files changed, 7 insertions(+)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 83a513efc824..3e36508610b7 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4877,6 +4877,8 @@ static long ext4_zero_range(struct file *file, loff_t offset,
/* Zero out partial block at the edges of the range */
ret = ext4_zero_partial_blocks(handle, inode, offset, len);
+ if (ret >= 0)
+ ext4_update_inode_fsync_trans(handle, inode, 1);
if (file->f_flags & O_SYNC)
ext4_handle_sync(handle);
@@ -5563,6 +5565,7 @@ int ext4_collapse_range(struct inode *inode, loff_t offset, loff_t len)
ext4_handle_sync(handle);
inode->i_mtime = inode->i_ctime = current_time(inode);
ext4_mark_inode_dirty(handle, inode);
+ ext4_update_inode_fsync_trans(handle, inode, 1);
out_stop:
ext4_journal_stop(handle);
@@ -5736,6 +5739,8 @@ int ext4_insert_range(struct inode *inode, loff_t offset, loff_t len)
up_write(&EXT4_I(inode)->i_data_sem);
if (IS_SYNC(inode))
ext4_handle_sync(handle);
+ if (ret >= 0)
+ ext4_update_inode_fsync_trans(handle, inode, 1);
out_stop:
ext4_journal_stop(handle);
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 14539ce38034..9475cb3cc5fc 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4221,6 +4221,8 @@ int ext4_punch_hole(struct inode *inode, loff_t offset, loff_t length)
inode->i_mtime = inode->i_ctime = current_time(inode);
ext4_mark_inode_dirty(handle, inode);
+ if (ret >= 0)
+ ext4_update_inode_fsync_trans(handle, inode, 1);
out_stop:
ext4_journal_stop(handle);
out_dio:
--
2.12.0
^ permalink raw reply related
* Re: [PATCH] clk: sunxi-ng: sun5i: Fix ahb_bist_clk definition
From: Angus Ainslie @ 2017-05-25 12:39 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Boris Brezillon, Maxime Ripard, Mike Turquette, Stephen Boyd,
linux-clk, linux-arm-kernel, stable
In-Reply-To: <CAGb2v66tpj4y2TdF2kz7Cb9fM-M1pBhuq137a80o0rjenF2AJA@mail.gmail.com>
On 2017-05-25 01:47, Chen-Yu Tsai wrote:
> On Thu, May 25, 2017 at 2:51 AM, Angus Ainslie <angus@akkea.ca> wrote:
>> On 2017-05-24 10:34, Boris Brezillon wrote:
>>>
>>> AHB BIST gate is actually controlled with bit 7.
>>>
>>> This bug was detected while trying to use the NAND controller which
>>> is
>>> using the DMA engine to transfer data to the NAND.
>>> Since the ahb_bist_clk gate bit conflicts with the ahb_dma_clk gate
>>> bit,
>>> the core was disabling the DMA engine clock as part of its 'disable
>>> unused clks' procedure, which was causing all DMA transfers to fail
>>> after
>>> this point.
>>>
>>> Fixes: 5e73761786d6 ("clk: sunxi-ng: Add sun5i CCU driver")
>>> Cc: stable@vger.kernel.org
>>> Reported-by: Angus Ainslie <angus@akkea.ca>compatible =
>>> "nextthing,chip-pro", "nextthing,gr8";
>>> Signed-off-by: Boris Brezillon <boris.brezillon@frecompatible =
>>> "nextthing,chip-pro", "nextthing,gr8";e-electrons.com>
>>> ---
>>> drivers/clk/sunxi-ng/ccu-sun5i.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.c
>>> b/drivers/clk/sunxi-ng/ccu-sun5i.c
>>> index 5c476f966a72..5372bf8be5e6 100644
>>> --- a/drivers/clk/sunxi-ng/ccu-sun5i.c
>>> +++ b/drivers/clk/sunxi-ng/ccu-sun5i.c
>>> @@ -243,7 +243,7 @@ static SUNXI_CCU_GATE(ahb_ss_clk, "ahb-ss",
>>> "ahb",
>>> static SUNXI_CCU_GATE(ahb_dma_clk, "ahb-dma", "ahb",
>>> 0x060, BIT(6), 0);
>>> static SUNXI_CCU_GATE(ahb_bist_clk, "ahb-bist", "ahb",
>>> - 0x060, BIT(6), 0);
>>> + 0x060, BIT(7), 0);
>>> static SUNXI_CCU_GATE(ahb_mmc0_clk, "ahb-mmc0", "ahb",
>>> 0x060, BIT(8), 0);
>>> static SUNXI_CCU_GATE(ahb_mmc1_clk, "ahb-mmc1", "ahb",
>>
>>
>>
>> The patch works perfectly. Using that I was able to remove the
>> clk_ignore_unsed and CLK_IS_CRITICAL.
>>
>
> Is that a Tested-by? :)
>
> ChenYu
Yeah :)
Tested-by: Angus Ainslie <angus@akkea.ca>
^ permalink raw reply
* [PATCH] ext4: Fix data corruption for mmap writes
From: Jan Kara @ 2017-05-25 11:46 UTC (permalink / raw)
To: Ted Tso; +Cc: linux-ext4, Michael Zimmer, Jan Kara, stable
mpage_submit_page() can race with another process growing i_size and
writing data via mmap to the written-back page. As mpage_submit_page()
samples i_size too early, it may happen that ext4_bio_write_page()
zeroes out too large tail of the page and thus corrupts user data.
Fix the problem by sampling i_size only after the page has been
write-protected in page tables by clear_page_dirty_for_io() call.
Reported-by: Michael Zimmer <michael@swarm64.com>
CC: stable@vger.kernel.org
Fixes: cb20d5188366f04d96d2e07b1240cc92170ade40
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext4/inode.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 1bd0bfa547f6..14539ce38034 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2124,15 +2124,29 @@ static int ext4_writepage(struct page *page,
static int mpage_submit_page(struct mpage_da_data *mpd, struct page *page)
{
int len;
- loff_t size = i_size_read(mpd->inode);
+ loff_t size;
int err;
BUG_ON(page->index != mpd->first_page);
+ clear_page_dirty_for_io(page);
+ /*
+ * We have to be very careful here! Nothing protects writeback path
+ * against i_size changes and the page can be writeably mapped into
+ * page tables. So an application can be growing i_size and writing
+ * data through mmap while writeback runs. clear_page_dirty_for_io()
+ * write-protects our page in page tables and the page cannot get
+ * written to again until we release page lock. So only after
+ * clear_page_dirty_for_io() we are safe to sample i_size for
+ * ext4_bio_write_page() to zero-out tail of the written page. We rely
+ * on the barrier provided by TestClearPageDirty in
+ * clear_page_dirty_for_io() to make sure i_size is really sampled only
+ * after page tables are updated.
+ */
+ size = i_size_read(mpd->inode);
if (page->index == size >> PAGE_SHIFT)
len = size & ~PAGE_MASK;
else
len = PAGE_SIZE;
- clear_page_dirty_for_io(page);
err = ext4_bio_write_page(&mpd->io_submit, page, len, mpd->wbc, false);
if (!err)
mpd->wbc->nr_to_write--;
--
2.12.0
^ permalink raw reply related
* Re: [PATCH 4.11 00/28] 4.11.1-stable review
From: Matt Fleming @ 2017-05-25 11:39 UTC (permalink / raw)
To: Shuah Khan
Cc: Greg Kroah-Hartman, linux-kernel, torvalds, akpm, linux, patches,
ben.hutchings, stable, Ard Biesheuvel, linux-efi
In-Reply-To: <e95d7992-6343-1a36-46e7-630b8874bdfa@osg.samsung.com>
On Mon, 15 May, at 11:28:16AM, Shuah Khan wrote:
> Hi Matt,
>
> On 05/15/2017 08:36 AM, Matt Fleming wrote:
> > On Fri, 12 May, at 10:01:41AM, Shuah Khan wrote:
> >>
> >> Greg/Matt,
> >>
> >> I started seeing this maybe since 4.11, so it isn't really a 4.11.1
> >> issue, however sounds like this shouldn't be an error message, since
> >> it is showing up on an older platform.
> >>
> >> efi: EFI_MEMMAP is not enabled.
> >> efi: Failed to lookup EFI memory descriptor for 0x00000000d9e0f018
> >>
> >>
> >> From 816e76129ed5fadd28e526c43397c79775194b5c Mon Sep 17 00:00:00 2001
> >> From: Matt Fleming <matt@codeblueprint.co.uk>
> >> Date: Mon, 29 Feb 2016 21:22:52 +0000
> >> Subject: [PATCH] efi: Allow drivers to reserve boot services forever
> >>
> >> This change was introduced in Commit: 816e76129ed5fadd28e526c43397c79775194b5c
> >>
> >> Matt!
> >>
> >> Shouldn't this be a debug message?? Is this a really an error??
> >
> > Yes, it's most likely an error. We shouldn't be trying to reserve
> > EFI regions if we can't find them in the memory map.
> >
> > Can you provide the full dmesg, please?
> >
>
> Please see attached dmesg and dmidecode output. Please let me know if you need
> any other information.
Did you use git bisect to find the above commit that introduced this
error message? Because while the error message itself was merged in
the above commit there were no users until commit 8e80632fb23f
("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()").
Can you apply the attached patch, boot your machine with the efi=debug
command line option and capture the dmesg output? It doesn't look like
your machine is booting using EFI.
---
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 30031d5293c4..7f942df48f42 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -193,6 +193,7 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
if (efi_mem_desc_lookup(addr, &md)) {
pr_err("Failed to lookup EFI memory descriptor for %pa\n", &addr);
+ WARN_ON(1);
return;
}
^ permalink raw reply related
* Re: [PATCH 4.9 000/164] 4.9.30-stable review
From: Greg Kroah-Hartman @ 2017-05-25 10:08 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <20170524202402.GB24768@roeck-us.net>
On Wed, May 24, 2017 at 01:24:02PM -0700, Guenter Roeck wrote:
> On Tue, May 23, 2017 at 10:06:57PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.30 release.
> > There are 164 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu May 25 20:08:20 UTC 2017.
> > Anything received after that time might be too late.
> >
> Note: This set of results is for v4.9.29-163-g6cdd061.
>
> Build results:
> total: 145 pass: 145 fail: 0
> Qemu test results:
> total: 122 pass: 122 fail: 0
>
> Details are available at http://kerneltests.org/builders.
Wonderful, thanks for testing all of these (twice a for some of these),
and letting me know they pass.
greg k-h
^ permalink raw reply
* Re: [PATCH] ptrace: Properly initialize ptracer_cred on fork
From: Greg Kroah-Hartman @ 2017-05-25 10:07 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: stable
In-Reply-To: <87inkqav8e.fsf@xmission.com>
On Wed, May 24, 2017 at 02:52:01PM -0500, Eric W. Biederman wrote:
>
> Enlightenment is broken in 4.11 and possibly other kernels where
> commit 64b875f7ac8a ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
> is backported to.
Has no one noticed it being broken on 4.10? That's where that commit
showed up, it seems odd we haven't had a bug report until now, right?
And the git commit id in that commit (4214e42f96d4), seems odd, where
did it come from?
> Can you please backport commit c70d9d809fde ("ptrace: Properly
> initialize ptracer_cred on fork") to the appropriate kernels.
I will queue it up for the next round after these are released.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] ext4: Fix data corruption with EXT4_GET_BLOCKS_ZERO
From: Jan Kara @ 2017-05-25 8:43 UTC (permalink / raw)
To: Ted Tso; +Cc: linux-ext4, Ross Zwisler, Jan Kara, stable
When ext4_map_blocks() is called with EXT4_GET_BLOCKS_ZERO to zero-out
allocated blocks and these blocks are actually converted from unwritten
extent the following race can happen:
CPU0 CPU1
page fault page fault
... ...
ext4_map_blocks()
ext4_ext_map_blocks()
ext4_ext_handle_unwritten_extents()
ext4_ext_convert_to_initialized()
- zero out converted extent
ext4_zeroout_es()
- inserts extent as initialized in status tree
ext4_map_blocks()
ext4_es_lookup_extent()
- finds initialized extent
write data
ext4_issue_zeroout()
- zeroes out new extent overwriting data
This problem can be reproduced by generic/340 for the fallocated case
for the last block in the file.
Fix the problem by avoiding zeroing out the area we are mapping with
ext4_map_blocks() in ext4_ext_convert_to_initialized(). It is pointless
to zero out this area in the first place as the caller asked us to
convert the area to initialized because he is just going to write data
there before the transaction finishes. To achieve this we delete the
special case of zeroing out full extent as that will be handled by the
cases below zeroing only the part of the extent that needs it. We also
instruct ext4_split_extent() that the middle of extent being split
contains data so that ext4_split_extent_at() cannot zero out full extent
in case of ENOSPC.
CC: stable@vger.kernel.org
Fixes: 12735f881952c32b31bc4e433768f18489f79ec9
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext4/extents.c | 80 +++++++++++++++++++++++++------------------------------
1 file changed, 37 insertions(+), 43 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 2a97dff87b96..83a513efc824 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -3413,13 +3413,13 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
struct ext4_sb_info *sbi;
struct ext4_extent_header *eh;
struct ext4_map_blocks split_map;
- struct ext4_extent zero_ex;
+ struct ext4_extent zero_ex1, zero_ex2;
struct ext4_extent *ex, *abut_ex;
ext4_lblk_t ee_block, eof_block;
unsigned int ee_len, depth, map_len = map->m_len;
int allocated = 0, max_zeroout = 0;
int err = 0;
- int split_flag = 0;
+ int split_flag = EXT4_EXT_DATA_VALID2;
ext_debug("ext4_ext_convert_to_initialized: inode %lu, logical"
"block %llu, max_blocks %u\n", inode->i_ino,
@@ -3436,7 +3436,8 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
ex = path[depth].p_ext;
ee_block = le32_to_cpu(ex->ee_block);
ee_len = ext4_ext_get_actual_len(ex);
- zero_ex.ee_len = 0;
+ zero_ex1.ee_len = 0;
+ zero_ex2.ee_len = 0;
trace_ext4_ext_convert_to_initialized_enter(inode, map, ex);
@@ -3576,62 +3577,52 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
if (ext4_encrypted_inode(inode))
max_zeroout = 0;
- /* If extent is less than s_max_zeroout_kb, zeroout directly */
- if (max_zeroout && (ee_len <= max_zeroout)) {
- err = ext4_ext_zeroout(inode, ex);
- if (err)
- goto out;
- zero_ex.ee_block = ex->ee_block;
- zero_ex.ee_len = cpu_to_le16(ext4_ext_get_actual_len(ex));
- ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(ex));
-
- err = ext4_ext_get_access(handle, inode, path + depth);
- if (err)
- goto out;
- ext4_ext_mark_initialized(ex);
- ext4_ext_try_to_merge(handle, inode, path, ex);
- err = ext4_ext_dirty(handle, inode, path + path->p_depth);
- goto out;
- }
-
/*
- * four cases:
+ * five cases:
* 1. split the extent into three extents.
- * 2. split the extent into two extents, zeroout the first half.
- * 3. split the extent into two extents, zeroout the second half.
+ * 2. split the extent into two extents, zeroout the head of the first
+ * extent.
+ * 3. split the extent into two extents, zeroout the tail of the second
+ * extent.
* 4. split the extent into two extents with out zeroout.
+ * 5. no splitting needed, just possibly zeroout the head and / or the
+ * tail of the extent.
*/
split_map.m_lblk = map->m_lblk;
split_map.m_len = map->m_len;
- if (max_zeroout && (allocated > map->m_len)) {
+ if (max_zeroout && (allocated > split_map.m_len)) {
if (allocated <= max_zeroout) {
- /* case 3 */
- zero_ex.ee_block =
- cpu_to_le32(map->m_lblk);
- zero_ex.ee_len = cpu_to_le16(allocated);
- ext4_ext_store_pblock(&zero_ex,
- ext4_ext_pblock(ex) + map->m_lblk - ee_block);
- err = ext4_ext_zeroout(inode, &zero_ex);
+ /* case 3 or 5 */
+ zero_ex1.ee_block =
+ cpu_to_le32(split_map.m_lblk +
+ split_map.m_len);
+ zero_ex1.ee_len =
+ cpu_to_le16(allocated - split_map.m_len);
+ ext4_ext_store_pblock(&zero_ex1,
+ ext4_ext_pblock(ex) + split_map.m_lblk +
+ split_map.m_len - ee_block);
+ err = ext4_ext_zeroout(inode, &zero_ex1);
if (err)
goto out;
- split_map.m_lblk = map->m_lblk;
split_map.m_len = allocated;
- } else if (map->m_lblk - ee_block + map->m_len < max_zeroout) {
- /* case 2 */
- if (map->m_lblk != ee_block) {
- zero_ex.ee_block = ex->ee_block;
- zero_ex.ee_len = cpu_to_le16(map->m_lblk -
+ }
+ if (split_map.m_lblk - ee_block + split_map.m_len <
+ max_zeroout) {
+ /* case 2 or 5 */
+ if (split_map.m_lblk != ee_block) {
+ zero_ex2.ee_block = ex->ee_block;
+ zero_ex2.ee_len = cpu_to_le16(split_map.m_lblk -
ee_block);
- ext4_ext_store_pblock(&zero_ex,
+ ext4_ext_store_pblock(&zero_ex2,
ext4_ext_pblock(ex));
- err = ext4_ext_zeroout(inode, &zero_ex);
+ err = ext4_ext_zeroout(inode, &zero_ex2);
if (err)
goto out;
}
+ split_map.m_len += split_map.m_lblk - ee_block;
split_map.m_lblk = ee_block;
- split_map.m_len = map->m_lblk - ee_block + map->m_len;
allocated = map->m_len;
}
}
@@ -3642,8 +3633,11 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
err = 0;
out:
/* If we have gotten a failure, don't zero out status tree */
- if (!err)
- err = ext4_zeroout_es(inode, &zero_ex);
+ if (!err) {
+ err = ext4_zeroout_es(inode, &zero_ex1);
+ if (!err)
+ err = ext4_zeroout_es(inode, &zero_ex2);
+ }
return err ? err : allocated;
}
--
2.12.0
^ permalink raw reply related
* Re: [PATCH] clk: sunxi-ng: sun5i: Fix ahb_bist_clk definition
From: Chen-Yu Tsai @ 2017-05-25 7:48 UTC (permalink / raw)
To: Boris Brezillon
Cc: Maxime Ripard, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
linux-clk, linux-arm-kernel, Angus Ainslie, stable
In-Reply-To: <1495643669-28221-1-git-send-email-boris.brezillon@free-electrons.com>
On Thu, May 25, 2017 at 12:34 AM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> AHB BIST gate is actually controlled with bit 7.
>
> This bug was detected while trying to use the NAND controller which is
> using the DMA engine to transfer data to the NAND.
> Since the ahb_bist_clk gate bit conflicts with the ahb_dma_clk gate bit,
> the core was disabling the DMA engine clock as part of its 'disable
> unused clks' procedure, which was causing all DMA transfers to fail after
> this point.
>
> Fixes: 5e73761786d6 ("clk: sunxi-ng: Add sun5i CCU driver")
> Cc: stable@vger.kernel.org
> Reported-by: Angus Ainslie <angus@akkea.ca>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* Re: [PATCH] clk: sunxi-ng: sun5i: Fix ahb_bist_clk definition
From: Chen-Yu Tsai @ 2017-05-25 7:47 UTC (permalink / raw)
To: Angus Ainslie
Cc: Boris Brezillon, Maxime Ripard, Chen-Yu Tsai, Mike Turquette,
Stephen Boyd, linux-clk, linux-arm-kernel, stable
In-Reply-To: <ad72ceff73364add5cfe25b6143a68ca@www.akkea.ca>
On Thu, May 25, 2017 at 2:51 AM, Angus Ainslie <angus@akkea.ca> wrote:
> On 2017-05-24 10:34, Boris Brezillon wrote:
>>
>> AHB BIST gate is actually controlled with bit 7.
>>
>> This bug was detected while trying to use the NAND controller which is
>> using the DMA engine to transfer data to the NAND.
>> Since the ahb_bist_clk gate bit conflicts with the ahb_dma_clk gate bit,
>> the core was disabling the DMA engine clock as part of its 'disable
>> unused clks' procedure, which was causing all DMA transfers to fail after
>> this point.
>>
>> Fixes: 5e73761786d6 ("clk: sunxi-ng: Add sun5i CCU driver")
>> Cc: stable@vger.kernel.org
>> Reported-by: Angus Ainslie <angus@akkea.ca>compatible =
>> "nextthing,chip-pro", "nextthing,gr8";
>> Signed-off-by: Boris Brezillon <boris.brezillon@frecompatible =
>> "nextthing,chip-pro", "nextthing,gr8";e-electrons.com>
>> ---
>> drivers/clk/sunxi-ng/ccu-sun5i.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.c
>> b/drivers/clk/sunxi-ng/ccu-sun5i.c
>> index 5c476f966a72..5372bf8be5e6 100644
>> --- a/drivers/clk/sunxi-ng/ccu-sun5i.c
>> +++ b/drivers/clk/sunxi-ng/ccu-sun5i.c
>> @@ -243,7 +243,7 @@ static SUNXI_CCU_GATE(ahb_ss_clk, "ahb-ss",
>> "ahb",
>> static SUNXI_CCU_GATE(ahb_dma_clk, "ahb-dma", "ahb",
>> 0x060, BIT(6), 0);
>> static SUNXI_CCU_GATE(ahb_bist_clk, "ahb-bist", "ahb",
>> - 0x060, BIT(6), 0);
>> + 0x060, BIT(7), 0);
>> static SUNXI_CCU_GATE(ahb_mmc0_clk, "ahb-mmc0", "ahb",
>> 0x060, BIT(8), 0);
>> static SUNXI_CCU_GATE(ahb_mmc1_clk, "ahb-mmc1", "ahb",
>
>
>
> The patch works perfectly. Using that I was able to remove the
> clk_ignore_unsed and CLK_IS_CRITICAL.
>
Is that a Tested-by? :)
ChenYu
^ permalink raw reply
* [PATCH v3] mlock: fix mlock count can not decrease in race condition
From: Yisheng Xie @ 2017-05-25 7:07 UTC (permalink / raw)
To: akpm
Cc: vbabka, joern, mgorman, walken, hughd, riel, hannes, mhocko,
qiuxishi, zhongjiang, guohanjun, wangkefeng.wang, stable,
linux-kernel, linux-mm
Kefeng reported that when running the follow test, the mlock count in
meminfo will increases permanently:
[1] testcase
linux:~ # cat test_mlockal
grep Mlocked /proc/meminfo
for j in `seq 0 10`
do
for i in `seq 4 15`
do
./p_mlockall >> log &
done
sleep 0.2
done
# wait some time to let mlock counter decrease and 5s may not enough
sleep 5
grep Mlocked /proc/meminfo
linux:~ # cat p_mlockall.c
#include <sys/mman.h>
#include <stdlib.h>
#include <stdio.h>
#define SPACE_LEN 4096
int main(int argc, char ** argv)
{
int ret;
void *adr = malloc(SPACE_LEN);
if (!adr)
return -1;
ret = mlockall(MCL_CURRENT | MCL_FUTURE);
printf("mlcokall ret = %d\n", ret);
ret = munlockall();
printf("munlcokall ret = %d\n", ret);
free(adr);
return 0;
}
In __munlock_pagevec() we should decrement NR_MLOCK for each page where
we clear the PageMlocked flag. Commit 1ebb7cc6a583 ("mm: munlock: batch
NR_MLOCK zone state updates") has introduced a bug where we don't
decrement NR_MLOCK for pages where we clear the flag, but fail to
isolate them from the lru list (e.g. when the pages are on some other
cpu's percpu pagevec). Since PageMlocked stays cleared, the NR_MLOCK
accounting gets permanently disrupted by this.
Fix it by counting the number of page whoes PageMlock flag is cleared.
Fixes: 1ebb7cc6a583 ("mm: munlock: batch NR_MLOCK zone state updates")
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Joern Engel <joern@logfs.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michel Lespinasse <walken@google.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Xishi Qiu <qiuxishi@huawei.com>
CC: zhongjiang <zhongjiang@huawei.com>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: <stable@vger.kernel.org>
---
v2:
- use delta_munlocked for it doesn't do the increment in fastpath - Vlastimil
v3:
- change the changelog to make it more clear - Vlastimil
Hi Andrew:
Could you please help to fold this?
Thanks
Yisheng Xie
mm/mlock.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/mlock.c b/mm/mlock.c
index c483c5c..b562b55 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -284,7 +284,7 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
{
int i;
int nr = pagevec_count(pvec);
- int delta_munlocked;
+ int delta_munlocked = -nr;
struct pagevec pvec_putback;
int pgrescued = 0;
@@ -304,6 +304,8 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
continue;
else
__munlock_isolation_failed(page);
+ } else {
+ delta_munlocked++;
}
/*
@@ -315,7 +317,6 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
pagevec_add(&pvec_putback, pvec->pages[i]);
pvec->pages[i] = NULL;
}
- delta_munlocked = -nr + pagevec_count(&pvec_putback);
__mod_zone_page_state(zone, NR_MLOCK, delta_munlocked);
spin_unlock_irq(zone_lru_lock(zone));
--
1.7.12.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH v2] mlock: fix mlock count can not decrease in race condition
From: Yisheng Xie @ 2017-05-25 6:48 UTC (permalink / raw)
To: Vlastimil Babka, akpm
Cc: joern, mgorman, walken, hughd, riel, hannes, mhocko, qiuxishi,
zhongjiang, guohanjun, wangkefeng.wang, stable, linux-kernel,
linux-mm
In-Reply-To: <6c19fa2f-36b6-d36b-3b51-7fdfc22e1a5c@suse.cz>
Hi Vlastimil,
Thanks for comment!
On 2017/5/25 14:32, Vlastimil Babka wrote:
> On 05/25/2017 04:13 AM, Yisheng Xie wrote:
>> Kefeng reported that when run the follow test the mlock count
>
>> in meminfo
>> cannot be decreased:
>
> "increases permanently."?
Yes if I am not mis-understanding what your means.
>
>> [1] testcase
>> linux:~ # cat test_mlockal
>> grep Mlocked /proc/meminfo
>> for j in `seq 0 10`
>> do
>> for i in `seq 4 15`
>> do
>> ./p_mlockall >> log &
>> done
>> sleep 0.2
>> done
>> # wait some time to let mlock counter decrease and 5s may not enough
>> sleep 5
>> grep Mlocked /proc/meminfo
>>
>> linux:~ # cat p_mlockall.c
>> #include <sys/mman.h>
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> #define SPACE_LEN 4096
>>
>> int main(int argc, char ** argv)
>> {
>> int ret;
>> void *adr = malloc(SPACE_LEN);
>> if (!adr)
>> return -1;
>>
>> ret = mlockall(MCL_CURRENT | MCL_FUTURE);
>> printf("mlcokall ret = %d\n", ret);
>>
>> ret = munlockall();
>> printf("munlcokall ret = %d\n", ret);
>>
>> free(adr);
>> return 0;
>> }
>>
>> When __munlock_pagevec, we ClearPageMlock but isolation_failed in race
>> condition, and we do not count these page into delta_munlocked, which cause
>> mlock counter incorrect for we had Clear the PageMlock and cannot count down
>> the number in the feture.
>
> Can I suggest the following instead:
>
> In __munlock_pagevec() we should decrement NR_MLOCK for each page where
> we clear the PageMlocked flag. Commit 1ebb7cc6a583 ("mm: munlock: batch
> NR_MLOCK zone state updates") has introduced a bug where we don't
> decrement NR_MLOCK for pages where we clear the flag, but fail to
> isolate them from the lru list (e.g. when the pages are on some other
> cpu's percpu pagevec). Since PageMlocked stays cleared, the NR_MLOCK
> accounting gets permanently disrupted by this.
That's much better and clear. Should I send another version ?
Thanks
Yisheng Xie
>
>> Fix it by count the number of page whoes PageMlock flag is cleared.
>>
>> Fixes: 1ebb7cc6a583 (" mm: munlock: batch NR_MLOCK zone state updates")
>> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
>> Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> Cc: Vlastimil Babka <vbabka@suse.cz>
>
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
>
> Thanks!
>
>> Cc: Joern Engel <joern@logfs.org>
>> Cc: Mel Gorman <mgorman@suse.de>
>> Cc: Michel Lespinasse <walken@google.com>
>> Cc: Hugh Dickins <hughd@google.com>
>> Cc: Rik van Riel <riel@redhat.com>
>> Cc: Johannes Weiner <hannes@cmpxchg.org>
>> Cc: Michal Hocko <mhocko@suse.cz>
>> Cc: Xishi Qiu <qiuxishi@huawei.com>
>> CC: zhongjiang <zhongjiang@huawei.com>
>> Cc: Hanjun Guo <guohanjun@huawei.com>
>> Cc: <stable@vger.kernel.org>
>> ---
>> v2:
>> - use delta_munlocked for it doesn't do the increment in fastpath - Vlastimil
>>
>> Hi Andrew:
>> Could you please help to fold this?
>>
>> Thanks
>> Yisheng Xie
>>
>> mm/mlock.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/mlock.c b/mm/mlock.c
>> index c483c5c..b562b55 100644
>> --- a/mm/mlock.c
>> +++ b/mm/mlock.c
>> @@ -284,7 +284,7 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
>> {
>> int i;
>> int nr = pagevec_count(pvec);
>> - int delta_munlocked;
>> + int delta_munlocked = -nr;
>> struct pagevec pvec_putback;
>> int pgrescued = 0;
>>
>> @@ -304,6 +304,8 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
>> continue;
>> else
>> __munlock_isolation_failed(page);
>> + } else {
>> + delta_munlocked++;
>> }
>>
>> /*
>> @@ -315,7 +317,6 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
>> pagevec_add(&pvec_putback, pvec->pages[i]);
>> pvec->pages[i] = NULL;
>> }
>> - delta_munlocked = -nr + pagevec_count(&pvec_putback);
>> __mod_zone_page_state(zone, NR_MLOCK, delta_munlocked);
>> spin_unlock_irq(zone_lru_lock(zone));
>>
>>
>
>
> .
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2] mlock: fix mlock count can not decrease in race condition
From: Vlastimil Babka @ 2017-05-25 6:32 UTC (permalink / raw)
To: Yisheng Xie, akpm
Cc: joern, mgorman, walken, hughd, riel, hannes, mhocko, qiuxishi,
zhongjiang, guohanjun, wangkefeng.wang, stable, linux-kernel,
linux-mm
In-Reply-To: <1495678405-54569-1-git-send-email-xieyisheng1@huawei.com>
On 05/25/2017 04:13 AM, Yisheng Xie wrote:
> Kefeng reported that when run the follow test the mlock count
> in meminfo
> cannot be decreased:
"increases permanently."?
> [1] testcase
> linux:~ # cat test_mlockal
> grep Mlocked /proc/meminfo
> for j in `seq 0 10`
> do
> for i in `seq 4 15`
> do
> ./p_mlockall >> log &
> done
> sleep 0.2
> done
> # wait some time to let mlock counter decrease and 5s may not enough
> sleep 5
> grep Mlocked /proc/meminfo
>
> linux:~ # cat p_mlockall.c
> #include <sys/mman.h>
> #include <stdlib.h>
> #include <stdio.h>
>
> #define SPACE_LEN 4096
>
> int main(int argc, char ** argv)
> {
> int ret;
> void *adr = malloc(SPACE_LEN);
> if (!adr)
> return -1;
>
> ret = mlockall(MCL_CURRENT | MCL_FUTURE);
> printf("mlcokall ret = %d\n", ret);
>
> ret = munlockall();
> printf("munlcokall ret = %d\n", ret);
>
> free(adr);
> return 0;
> }
>
> When __munlock_pagevec, we ClearPageMlock but isolation_failed in race
> condition, and we do not count these page into delta_munlocked, which cause
> mlock counter incorrect for we had Clear the PageMlock and cannot count down
> the number in the feture.
Can I suggest the following instead:
In __munlock_pagevec() we should decrement NR_MLOCK for each page where
we clear the PageMlocked flag. Commit 1ebb7cc6a583 ("mm: munlock: batch
NR_MLOCK zone state updates") has introduced a bug where we don't
decrement NR_MLOCK for pages where we clear the flag, but fail to
isolate them from the lru list (e.g. when the pages are on some other
cpu's percpu pagevec). Since PageMlocked stays cleared, the NR_MLOCK
accounting gets permanently disrupted by this.
> Fix it by count the number of page whoes PageMlock flag is cleared.
>
> Fixes: 1ebb7cc6a583 (" mm: munlock: batch NR_MLOCK zone state updates")
> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
> Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> Cc: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Thanks!
> Cc: Joern Engel <joern@logfs.org>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Michel Lespinasse <walken@google.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Michal Hocko <mhocko@suse.cz>
> Cc: Xishi Qiu <qiuxishi@huawei.com>
> CC: zhongjiang <zhongjiang@huawei.com>
> Cc: Hanjun Guo <guohanjun@huawei.com>
> Cc: <stable@vger.kernel.org>
> ---
> v2:
> - use delta_munlocked for it doesn't do the increment in fastpath - Vlastimil
>
> Hi Andrew:
> Could you please help to fold this?
>
> Thanks
> Yisheng Xie
>
> mm/mlock.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mlock.c b/mm/mlock.c
> index c483c5c..b562b55 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -284,7 +284,7 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
> {
> int i;
> int nr = pagevec_count(pvec);
> - int delta_munlocked;
> + int delta_munlocked = -nr;
> struct pagevec pvec_putback;
> int pgrescued = 0;
>
> @@ -304,6 +304,8 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
> continue;
> else
> __munlock_isolation_failed(page);
> + } else {
> + delta_munlocked++;
> }
>
> /*
> @@ -315,7 +317,6 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
> pagevec_add(&pvec_putback, pvec->pages[i]);
> pvec->pages[i] = NULL;
> }
> - delta_munlocked = -nr + pagevec_count(&pvec_putback);
> __mod_zone_page_state(zone, NR_MLOCK, delta_munlocked);
> spin_unlock_irq(zone_lru_lock(zone));
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH v2] mlock: fix mlock count can not decrease in race condition
From: Yisheng Xie @ 2017-05-25 2:13 UTC (permalink / raw)
To: akpm
Cc: vbabka, joern, mgorman, walken, hughd, riel, hannes, mhocko,
qiuxishi, zhongjiang, guohanjun, wangkefeng.wang, stable,
linux-kernel, linux-mm
Kefeng reported that when run the follow test the mlock count in meminfo
cannot be decreased:
[1] testcase
linux:~ # cat test_mlockal
grep Mlocked /proc/meminfo
for j in `seq 0 10`
do
for i in `seq 4 15`
do
./p_mlockall >> log &
done
sleep 0.2
done
# wait some time to let mlock counter decrease and 5s may not enough
sleep 5
grep Mlocked /proc/meminfo
linux:~ # cat p_mlockall.c
#include <sys/mman.h>
#include <stdlib.h>
#include <stdio.h>
#define SPACE_LEN 4096
int main(int argc, char ** argv)
{
int ret;
void *adr = malloc(SPACE_LEN);
if (!adr)
return -1;
ret = mlockall(MCL_CURRENT | MCL_FUTURE);
printf("mlcokall ret = %d\n", ret);
ret = munlockall();
printf("munlcokall ret = %d\n", ret);
free(adr);
return 0;
}
When __munlock_pagevec, we ClearPageMlock but isolation_failed in race
condition, and we do not count these page into delta_munlocked, which cause
mlock counter incorrect for we had Clear the PageMlock and cannot count down
the number in the feture.
Fix it by count the number of page whoes PageMlock flag is cleared.
Fixes: 1ebb7cc6a583 (" mm: munlock: batch NR_MLOCK zone state updates")
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Joern Engel <joern@logfs.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michel Lespinasse <walken@google.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Xishi Qiu <qiuxishi@huawei.com>
CC: zhongjiang <zhongjiang@huawei.com>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: <stable@vger.kernel.org>
---
v2:
- use delta_munlocked for it doesn't do the increment in fastpath - Vlastimil
Hi Andrew:
Could you please help to fold this?
Thanks
Yisheng Xie
mm/mlock.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/mlock.c b/mm/mlock.c
index c483c5c..b562b55 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -284,7 +284,7 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
{
int i;
int nr = pagevec_count(pvec);
- int delta_munlocked;
+ int delta_munlocked = -nr;
struct pagevec pvec_putback;
int pgrescued = 0;
@@ -304,6 +304,8 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
continue;
else
__munlock_isolation_failed(page);
+ } else {
+ delta_munlocked++;
}
/*
@@ -315,7 +317,6 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
pagevec_add(&pvec_putback, pvec->pages[i]);
pvec->pages[i] = NULL;
}
- delta_munlocked = -nr + pagevec_count(&pvec_putback);
__mod_zone_page_state(zone, NR_MLOCK, delta_munlocked);
spin_unlock_irq(zone_lru_lock(zone));
--
1.7.12.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* + mlock-fix-mlock-count-can-not-decrease-in-race-condition.patch added to -mm tree
From: akpm @ 2017-05-24 22:04 UTC (permalink / raw)
To: xieyisheng1, hannes, hughd, joern, mgorman, mhocko, riel, stable,
vbabka, walken, wangkefeng.wang, mm-commits
The patch titled
Subject: mm/mlock.c: fix mlock count can not decrease in race condition
has been added to the -mm tree. Its filename is
mlock-fix-mlock-count-can-not-decrease-in-race-condition.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mlock-fix-mlock-count-can-not-decrease-in-race-condition.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mlock-fix-mlock-count-can-not-decrease-in-race-condition.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Yisheng Xie <xieyisheng1@huawei.com>
Subject: mm/mlock.c: fix mlock count can not decrease in race condition
Kefeng reported that when running the follow test the mlock count in
meminfo cannot be decreased:
[1] testcase
linux:~ # cat test_mlockal
grep Mlocked /proc/meminfo
for j in `seq 0 10`
do
for i in `seq 4 15`
do
./p_mlockall >> log &
done
sleep 0.2
done
# wait some time to let mlock counter decrease and 5s may not enough
sleep 5
grep Mlocked /proc/meminfo
linux:~ # cat p_mlockall.c
#include <sys/mman.h>
#include <stdlib.h>
#include <stdio.h>
#define SPACE_LEN 4096
int main(int argc, char ** argv)
{
int ret;
void *adr = malloc(SPACE_LEN);
if (!adr)
return -1;
ret = mlockall(MCL_CURRENT | MCL_FUTURE);
printf("mlcokall ret = %d\n", ret);
ret = munlockall();
printf("munlcokall ret = %d\n", ret);
free(adr);
return 0;
}
In __munlock_pagevec() we ClearPageMlock but isolation_failed in race
condition, and we do not count these page into delta_munlocked, which
causes mlock counter inaccuracy because we cleared the PageMlock and
cannot count down the number in the future.
Fix it by counting the number of pages whose PageMlock flag is cleared.
Fixes 1ebb7cc6a583 (" mm: munlock: batch NR_MLOCK zone state updates")
Link: http://lkml.kernel.org/r/1495620504-7007-1-git-send-email-xieyisheng1@huawei.com
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Joern Engel <joern@logfs.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michel Lespinasse <walken@google.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/mlock.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff -puN mm/mlock.c~mlock-fix-mlock-count-can-not-decrease-in-race-condition mm/mlock.c
--- a/mm/mlock.c~mlock-fix-mlock-count-can-not-decrease-in-race-condition
+++ a/mm/mlock.c
@@ -284,7 +284,7 @@ static void __munlock_pagevec(struct pag
{
int i;
int nr = pagevec_count(pvec);
- int delta_munlocked;
+ int munlocked = 0;
struct pagevec pvec_putback;
int pgrescued = 0;
@@ -296,6 +296,7 @@ static void __munlock_pagevec(struct pag
struct page *page = pvec->pages[i];
if (TestClearPageMlocked(page)) {
+ munlocked --;
/*
* We already have pin from follow_page_mask()
* so we can spare the get_page() here.
@@ -315,8 +316,8 @@ static void __munlock_pagevec(struct pag
pagevec_add(&pvec_putback, pvec->pages[i]);
pvec->pages[i] = NULL;
}
- delta_munlocked = -nr + pagevec_count(&pvec_putback);
- __mod_zone_page_state(zone, NR_MLOCK, delta_munlocked);
+ if (munlocked)
+ __mod_zone_page_state(zone, NR_MLOCK, munlocked);
spin_unlock_irq(zone_lru_lock(zone));
/* Now we can release pins of pages that we are not munlocking */
_
Patches currently in -mm which might be from xieyisheng1@huawei.com are
mlock-fix-mlock-count-can-not-decrease-in-race-condition.patch
^ permalink raw reply
* Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback
From: Andy Lutomirski @ 2017-05-24 22:00 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Greg KH, Daniel Wagner, David Woodhouse, jewalt, rafal,
arend.vanspriel, Rafael J. Wysocki, yi1.li, atull, moritz.fischer,
Petr Mladek, Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Kalle Valo, Andrew Lutomirski, Linus Torvalds, Kees Cook,
AKASHI Takahiro, David Howells, Peter Jones, Hans de Goede,
Alan Cox, Ted Ts'o, linux-kernel@vger.kernel.org,
Martin Fuzzey, stable # 4 . 0
In-Reply-To: <20170524214027.7775-1-mcgrof@kernel.org>
On Wed, May 24, 2017 at 2:40 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> From: Martin Fuzzey <mfuzzey@parkeon.com>
>
> Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion
> is interrupted") added via 4.0 added support to abort the fallback mechanism
> when a signal was detected and wait_for_completion_interruptible() returned
> -ERESTARTSYS. Although the abort was effective we were unfortunately never
> really propagating this error though and as such userspace could not know
> why the abort happened.
Can you give a simple example of what's going on and why it matters?
ERESTARTSYS and friends are highly magical, and I'm not convinced that
allowing _request_firmware_load to return -ERESTARTSYS is actually a
good idea. What if there are system calls that can't handle this
style of restart that start being restarted as a result?
^ permalink raw reply
* [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback
From: Luis R. Rodriguez @ 2017-05-24 21:40 UTC (permalink / raw)
To: gregkh
Cc: wagi, dwmw2, jewalt, rafal, arend.vanspriel, rjw, yi1.li, atull,
moritz.fischer, pmladek, johannes.berg, emmanuel.grumbach,
luciano.coelho, kvalo, luto, torvalds, keescook, takahiro.akashi,
dhowells, pjones, hdegoede, alan, tytso, linux-kernel,
Martin Fuzzey, stable # 4 . 0, Luis R . Rodriguez
In-Reply-To: <20170524205658.GK8951@wotan.suse.de>
From: Martin Fuzzey <mfuzzey@parkeon.com>
Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion
is interrupted") added via 4.0 added support to abort the fallback mechanism
when a signal was detected and wait_for_completion_interruptible() returned
-ERESTARTSYS. Although the abort was effective we were unfortunately never
really propagating this error though and as such userspace could not know
why the abort happened.
The error code was always being lost to an even older change, commit
0542ad88fbdd81bb ("firmware loader: Fix _request_firmware_load() return val
for fw load abort") by Shuah Khan which was merged since v3.17. Back then
though we never were capturing these signals or bailing on a signal. After
this change though only only -EAGAIN was being relayed back to userspace
on non-memory errors including signals trying to interrupt our fallback
process.
It only makes sense to fix capturing -ERESTARTSYS since we were capturing
the error but when it was actually effective, since commit 0cb64249ca500
("firmware_loader: abort request if wait_for_completion is interrupted").
Only distributions relying on the fallback mechanism are impacted. An
example issue is on Android, when request_firmware() is called through
the firmware fallback mechanism -- syfs write call, sysfs .store(), and
Android sends a SIGCHLD to fail the write call -- in such cases the fact
that we failed due to a signal is lost.
Fix this and ensure we propagate -ERESTARTSYS so that handlers can
whether or not to restart write calls.
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
Cc: stable <stable@vger.kernel.org> # 4.0
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
[mcgrof: gave the commit log some serious love]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
For those following drivers/base/firmware_class.c development -- I've pushed
out two new branches based on linux-next tag next-20170524, one is just the
driver-data API [0], and the other one just has this patch applied on top
of the driver-data API [1]. You'll want to use driver-data-stable if you are
working on the cache or the fallback mechanism since this fix does provide
a fix for the cache / fallback mechanism.
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170524-driver-data
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170524-driver-data-stable
Luis
drivers/base/firmware_class.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 7af430a2d656..77c0e0792c30 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1309,9 +1309,10 @@ static int _request_firmware_load(struct firmware_priv *fw_priv,
mutex_unlock(&fw_lock);
}
- if (fw_state_is_aborted(&buf->fw_st))
- retval = -EAGAIN;
- else if (buf->is_paged_buf && !buf->data)
+ if (fw_state_is_aborted(&buf->fw_st)) {
+ if (retval != -ERESTARTSYS)
+ retval = -EAGAIN;
+ } else if (buf->is_paged_buf && !buf->data)
retval = -ENOMEM;
device_del(f_dev);
--
2.10.2
^ permalink raw reply related
* + mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified.patch added to -mm tree
From: akpm @ 2017-05-24 21:25 UTC (permalink / raw)
To: james.morse, kirill.shutemov, n-horiguchi, punit.agrawal, stable,
mm-commits
The patch titled
Subject: mm/hugetlb: report -EHWPOISON not -EFAULT when FOLL_HWPOISON is specified
has been added to the -mm tree. Its filename is
mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: James Morse <james.morse@arm.com>
Subject: mm/hugetlb: report -EHWPOISON not -EFAULT when FOLL_HWPOISON is specified
KVM uses get_user_pages() to resolve its stage2 faults. KVM sets the
FOLL_HWPOISON flag causing faultin_page() to return -EHWPOISON when it
finds a VM_FAULT_HWPOISON. KVM handles these hwpoison pages as a special
case. (check_user_page_hwpoison())
When huge pages are involved, this doesn't work so well. get_user_pages()
calls follow_hugetlb_page(), which stops early if it receives
VM_FAULT_HWPOISON from hugetlb_fault(), eventually returning -EFAULT to
the caller. The step to map this to -EHWPOISON based on the FOLL_ flags
is missing. The hwpoison special case is skipped, and -EFAULT is returned
to user-space, causing Qemu or kvmtool to exit.
Instead, move this VM_FAULT_ to errno mapping code into a header file and
use it from faultin_page() and follow_hugetlb_page().
With this, KVM works as expected.
This isn't a problem for arm64 today as we haven't enabled MEMORY_FAILURE,
but I can't see any reason this doesn't happen on x86 too, so I think this
should be a fix. This doesn't apply earlier than stable's v4.11.1 due to
all sorts of cleanup.
Link: http://lkml.kernel.org/r/20170524160900.28786-1-james.morse@arm.com
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Punit Agrawal <punit.agrawal@arm.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: <stable@vger.kernel.org> [4.11.1+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/mm.h | 10 ++++++++++
mm/gup.c | 9 +++------
mm/hugetlb.c | 3 +++
3 files changed, 16 insertions(+), 6 deletions(-)
diff -puN include/linux/mm.h~mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified include/linux/mm.h
--- a/include/linux/mm.h~mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified
+++ a/include/linux/mm.h
@@ -2327,6 +2327,16 @@ static inline struct page *follow_page(s
#define FOLL_REMOTE 0x2000 /* we are working on non-current tsk/mm */
#define FOLL_COW 0x4000 /* internal GUP flag */
+static inline int vm_fault_to_errno(int vm_fault, int foll_flags) {
+ if (vm_fault & VM_FAULT_OOM)
+ return -ENOMEM;
+ if (vm_fault & (VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE))
+ return (foll_flags & FOLL_HWPOISON) ? -EHWPOISON : -EFAULT;
+ if (vm_fault & (VM_FAULT_SIGBUS | VM_FAULT_SIGSEGV))
+ return -EFAULT;
+ return 0;
+}
+
typedef int (*pte_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr,
void *data);
extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
diff -puN mm/gup.c~mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified mm/gup.c
--- a/mm/gup.c~mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified
+++ a/mm/gup.c
@@ -481,12 +481,9 @@ static int faultin_page(struct task_stru
ret = handle_mm_fault(vma, address, fault_flags);
if (ret & VM_FAULT_ERROR) {
- if (ret & VM_FAULT_OOM)
- return -ENOMEM;
- if (ret & (VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE))
- return *flags & FOLL_HWPOISON ? -EHWPOISON : -EFAULT;
- if (ret & (VM_FAULT_SIGBUS | VM_FAULT_SIGSEGV))
- return -EFAULT;
+ int err = vm_fault_to_errno(ret, *flags);
+ if (err)
+ return err;
BUG();
}
diff -puN mm/hugetlb.c~mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified
+++ a/mm/hugetlb.c
@@ -4186,7 +4186,10 @@ long follow_hugetlb_page(struct mm_struc
}
ret = hugetlb_fault(mm, vma, vaddr, fault_flags);
if (ret & VM_FAULT_ERROR) {
+ int err = vm_fault_to_errno(ret, flags);
remainder = 0;
+ if (err)
+ return err;
break;
}
if (ret & VM_FAULT_RETRY) {
_
Patches currently in -mm which might be from james.morse@arm.com are
mm-hugetlb-report-ehwpoison-not-efault-when-foll_hwpoison-is-specified.patch
^ permalink raw reply
* Re: [PATCH 4.9 000/164] 4.9.30-stable review
From: Guenter Roeck @ 2017-05-24 20:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <20170523200907.297534241@linuxfoundation.org>
On Tue, May 23, 2017 at 10:06:57PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.30 release.
> There are 164 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu May 25 20:08:20 UTC 2017.
> Anything received after that time might be too late.
>
Note: This set of results is for v4.9.29-163-g6cdd061.
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Guenter Roeck @ 2017-05-24 20:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <20170523200856.903752266@linuxfoundation.org>
On Tue, May 23, 2017 at 10:08:26PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.70 release.
> There are 103 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu May 25 20:08:25 UTC 2017.
> Anything received after that time might be too late.
>
Note: This set of results is for v4.4.69-102-g3a21698.
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 115 pass: 115 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply
* [PATCH] ptrace: Properly initialize ptracer_cred on fork
From: Eric W. Biederman @ 2017-05-24 19:52 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: stable
Enlightenment is broken in 4.11 and possibly other kernels where
commit 64b875f7ac8a ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
is backported to.
Can you please backport commit c70d9d809fde ("ptrace: Properly
initialize ptracer_cred on fork") to the appropriate kernels.
Thank you,
Eric Beiderman
>From c70d9d809fdeecedb96972457ee45c49a232d97f Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Mon, 22 May 2017 15:40:12 -0500
Subject: [PATCH] ptrace: Properly initialize ptracer_cred on fork
When I introduced ptracer_cred I failed to consider the weirdness of
fork where the task_struct copies the old value by default. This
winds up leaving ptracer_cred set even when a process forks and
the child process does not wind up being ptraced.
Because ptracer_cred is not set on non-ptraced processes whose
parents were ptraced this has broken the ability of the enlightenment
window manager to start setuid children.
Fix this by properly initializing ptracer_cred in ptrace_init_task
This must be done with a little bit of care to preserve the current value
of ptracer_cred when ptrace carries through fork. Re-reading the
ptracer_cred from the ptracing process at this point is inconsistent
with how PT_PTRACE_CAP has been maintained all of these years.
Tested-by: Takashi Iwai <tiwai@suse.de>
Fixes: 64b875f7ac8a ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
include/linux/ptrace.h | 7 +++++--
kernel/ptrace.c | 20 +++++++++++++-------
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 422bc2e4cb6a..ef3eb8bbfee4 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -54,7 +54,8 @@ extern int ptrace_request(struct task_struct *child, long request,
unsigned long addr, unsigned long data);
extern void ptrace_notify(int exit_code);
extern void __ptrace_link(struct task_struct *child,
- struct task_struct *new_parent);
+ struct task_struct *new_parent,
+ const struct cred *ptracer_cred);
extern void __ptrace_unlink(struct task_struct *child);
extern void exit_ptrace(struct task_struct *tracer, struct list_head *dead);
#define PTRACE_MODE_READ 0x01
@@ -206,7 +207,7 @@ static inline void ptrace_init_task(struct task_struct *child, bool ptrace)
if (unlikely(ptrace) && current->ptrace) {
child->ptrace = current->ptrace;
- __ptrace_link(child, current->parent);
+ __ptrace_link(child, current->parent, current->ptracer_cred);
if (child->ptrace & PT_SEIZED)
task_set_jobctl_pending(child, JOBCTL_TRAP_STOP);
@@ -215,6 +216,8 @@ static inline void ptrace_init_task(struct task_struct *child, bool ptrace)
set_tsk_thread_flag(child, TIF_SIGPENDING);
}
+ else
+ child->ptracer_cred = NULL;
}
/**
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 266ddcc1d8bb..60f356d91060 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -60,19 +60,25 @@ int ptrace_access_vm(struct task_struct *tsk, unsigned long addr,
}
+void __ptrace_link(struct task_struct *child, struct task_struct *new_parent,
+ const struct cred *ptracer_cred)
+{
+ BUG_ON(!list_empty(&child->ptrace_entry));
+ list_add(&child->ptrace_entry, &new_parent->ptraced);
+ child->parent = new_parent;
+ child->ptracer_cred = get_cred(ptracer_cred);
+}
+
/*
* ptrace a task: make the debugger its new parent and
* move it to the ptrace list.
*
* Must be called with the tasklist lock write-held.
*/
-void __ptrace_link(struct task_struct *child, struct task_struct *new_parent)
+static void ptrace_link(struct task_struct *child, struct task_struct *new_parent)
{
- BUG_ON(!list_empty(&child->ptrace_entry));
- list_add(&child->ptrace_entry, &new_parent->ptraced);
- child->parent = new_parent;
rcu_read_lock();
- child->ptracer_cred = get_cred(__task_cred(new_parent));
+ __ptrace_link(child, new_parent, __task_cred(new_parent));
rcu_read_unlock();
}
@@ -386,7 +392,7 @@ static int ptrace_attach(struct task_struct *task, long request,
flags |= PT_SEIZED;
task->ptrace = flags;
- __ptrace_link(task, current);
+ ptrace_link(task, current);
/* SEIZE doesn't trap tracee on attach */
if (!seize)
@@ -459,7 +465,7 @@ static int ptrace_traceme(void)
*/
if (!ret && !(current->real_parent->flags & PF_EXITING)) {
current->ptrace = PT_PTRACED;
- __ptrace_link(current, current->real_parent);
+ ptrace_link(current, current->real_parent);
}
}
write_unlock_irq(&tasklist_lock);
--
2.10.1
^ permalink raw reply related
* Re: [PATCH v2] acpi: fix acpi_get_table() leak / acpi-sysfs denial of service
From: Dan Williams @ 2017-05-24 19:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael Wysocki, Anush Seetharaman, Tiffany Kasanicky, Ryon Jensen,
Linux Kernel Mailing List, Stable, ACPI Devel Maling List,
Kristin Jacque, Zhang Rui
In-Reply-To: <CAPcyv4i_mRLSxm7YAnk_p8PhP=kyhT1aZZcrG-zZxXXWhGQuew@mail.gmail.com>
On Wed, Apr 26, 2017 at 3:37 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Wed, Apr 26, 2017 at 3:25 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Tue, Apr 25, 2017 at 9:58 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>>> Reading an ACPI table through the /sys/firmware/acpi/tables interface
>>> more than 65,536 times leads to the following log message:
>>>
>>> ACPI Error: Table ffff88033595eaa8, Validation count is zero after increment
>>> (20170119/tbutils-423)
>>>
>>> ...and the table being unavailable until the next reboot. Add the
>>> missing acpi_put_table() so the table ->validation_count is decremented
>>> after each read.
>>>
>>> Cc: <stable@vger.kernel.org>
>>> Cc: Zhang Rui <rui.zhang@intel.com>
>>> Cc: Rafael Wysocki <rafael.j.wysocki@intel.com>
>>> Cc: Kristin Jacque <kristin.jacque@intel.com>
>>> Cc: Tiffany Kasanicky <tiffany.j.kasanicky@intel.com>
>>> Cc: Ryon Jensen <ryon.jensen@intel.com>
>>> Reported-by: Anush Seetharaman <anush.seetharaman@intel.com>
>>> Fixes: 1c8fce27e275 ("ACPI: introduce drivers/acpi/sysfs.c")
>>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>>
>> I'm going to apply this, but your Fixes tag is not correct.
>>
>> validation_count was added to struct acpi_table_desc by commit
>>
>> commit 174cc7187e6f088942c8e74daa7baff7b44b33c9
>> Author: Lv Zheng <lv.zheng@intel.com>
>> Date: Wed Dec 14 15:04:25 2016 +0800
>>
>> ACPICA: Tables: Back port acpi_get_table_with_size() and
>> early_acpi_os_unmap_memory()
>> from Linux kernel
>>
>> from the 4.10 time frame, so IMO it should be
>>
>> Fixes: 174cc7187e6f (ACPICA: Tables: Back port
>> acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux
>> kernel)
>>
>
> Ah, thanks for the catch, I missed that detail and was wrong to argue
> it was a 7 year old bug. Apologies Lv!
Hi Rafael, I don't see this in latest Linus master or queued in your
bleeding-edge branch.
^ permalink raw reply
* Re: [PATCH] clk: sunxi-ng: sun5i: Fix ahb_bist_clk definition
From: Angus Ainslie @ 2017-05-24 18:51 UTC (permalink / raw)
To: Boris Brezillon
Cc: Maxime Ripard, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
linux-clk, linux-arm-kernel, stable
In-Reply-To: <1495643669-28221-1-git-send-email-boris.brezillon@free-electrons.com>
On 2017-05-24 10:34, Boris Brezillon wrote:
> AHB BIST gate is actually controlled with bit 7.
>
> This bug was detected while trying to use the NAND controller which is
> using the DMA engine to transfer data to the NAND.
> Since the ahb_bist_clk gate bit conflicts with the ahb_dma_clk gate
> bit,
> the core was disabling the DMA engine clock as part of its 'disable
> unused clks' procedure, which was causing all DMA transfers to fail
> after
> this point.
>
> Fixes: 5e73761786d6 ("clk: sunxi-ng: Add sun5i CCU driver")
> Cc: stable@vger.kernel.org
> Reported-by: Angus Ainslie <angus@akkea.ca>compatible =
> "nextthing,chip-pro", "nextthing,gr8";
> Signed-off-by: Boris Brezillon <boris.brezillon@frecompatible =
> "nextthing,chip-pro", "nextthing,gr8";e-electrons.com>
> ---
> drivers/clk/sunxi-ng/ccu-sun5i.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.c
> b/drivers/clk/sunxi-ng/ccu-sun5i.c
> index 5c476f966a72..5372bf8be5e6 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun5i.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun5i.c
> @@ -243,7 +243,7 @@ static SUNXI_CCU_GATE(ahb_ss_clk, "ahb-ss", "ahb",
> static SUNXI_CCU_GATE(ahb_dma_clk, "ahb-dma", "ahb",
> 0x060, BIT(6), 0);
> static SUNXI_CCU_GATE(ahb_bist_clk, "ahb-bist", "ahb",
> - 0x060, BIT(6), 0);
> + 0x060, BIT(7), 0);
> static SUNXI_CCU_GATE(ahb_mmc0_clk, "ahb-mmc0", "ahb",
> 0x060, BIT(8), 0);
> static SUNXI_CCU_GATE(ahb_mmc1_clk, "ahb-mmc1", "ahb",
The patch works perfectly. Using that I was able to remove the
clk_ignore_unsed and CLK_IS_CRITICAL.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox