This might be related to https://bugzilla.kernel.org/show_bug.cgi?id=195215
Could you have the user try this change?
https://bugzilla.kernel.org/show_bug.cgi?id=195215#c12
On Fri, Jun 02, 2017 at 10:54:52AM -0700, Laura Abbott wrote:
> Hi,
>
> Fedora got a bug report https://bugzilla.redhat.com
On Fri, Jun 2, 2017 at 8:20 AM, wrote:
> From: Rik van Riel
>
> When setting up mmap_base, we take care to start the mmap base
> below the maximum extent to which the stack will grow. However,
> we take no such precautions with PIE binaries, which are placed
> at 5/6 of TASK_SIZE plus a random o
Hi Stephen,
[auto build test ERROR on sunxi/sunxi/for-next]
[also build test ERROR on next-20170602]
[cannot apply to clk/clk-next v4.12-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
I resend this mail due to I forgot to change it to text mode and was
blocked from some servers. Sorry for the inconvenience.
2017-05-25 20:58 GMT+08:00 Rick Chang :
> hi
>
> I would like to provide a lock module to solve the problem as follows:
>
> I want to efficiently use different resources (ex
On Fri, Jun 2, 2017 at 8:20 AM, wrote:
> There are a few bugs causing the kernel to sometimes map PIE
> binaries and the mmap_area where the stack is supposed to go.
>
> This series fixes them for x86, ARM64, and PPC.
> S390 seems to be ok.
>
> If people are fine with this approach, I can work my
On Fri, Jun 2, 2017 at 8:20 AM, wrote:
> From: Rik van Riel
>
> When RLIMIT_STACK is, for example, 256MB, the current code results in
> a gap between the top of the task and mmap_base of 256MB, failing to
> take into account the amount by which the stack address was randomized.
> In other words,
On Sat, Jun 03, 2017 at 01:58:25AM +0200, Jason A. Donenfeld wrote:
> Hi Ted,
>
> Based on the tone of your last email, before I respond to your
> individual points
May I gently point out that *your* tone that started this whole thread
has been pretty terrible? Quoting your your first messa
Commit 9520ed8fb841 ("net: dsa: use cpu_switch instead of ds[0]")
replaced the use of dst->ds[0] with dst->cpu_switch since that is
functionally equivalent, however, we can now run into an use after free
scenario after unbinding then rebinding the switch driver.
The use after free happens because
On Fri, Jun 2, 2017 at 2:32 PM, Daniel Micay wrote:
> On Fri, 2017-06-02 at 14:07 -0700, Andrew Morton wrote:
>> On Fri, 26 May 2017 05:54:04 -0400 Daniel Micay > > wrote:
>>
>> > This adds support for compiling with a rough equivalent to the glibc
>> > _FORTIFY_SOURCE=1 feature, providing compile
On Fri, 2 Jun 2017, Paul E. McKenney wrote:
> On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote:
> > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote:
> > > On Fri, 12 May 2017, Paul E. McKenney wrote:
>
> [ . . . ]
>
> > > No. "Available in mainline" is the name of
On Fri, Jun 02, 2017 at 04:46:40PM +0300, Sagi Grimberg wrote:
>
>> switch (type) {
>> case NVME_NQN_NVME:
>> diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h
>> index cfc5c7fb0ab7..4c6cb5ea1186 100644
>> --- a/drivers/nvme/target/nvmet.h
>> +++ b/drivers/nvme/target
Hi all,
On the latest linux-next I'm seeing issues that look like an icmp
socket destruction racing with poll(). It manifests in two ways, first:
BUG: KASAN: slab-out-of-bounds in skb_queue_empty include/linux/skbuff.h:1197
[inline]
BUG: KASAN: slab-out-of-bounds in udp_poll+0x5fb/0x6f0 net/ipv4
On Fri, Jun 2, 2017 at 6:12 PM, Al Viro wrote:
> Part of that could be relieved if we turned check_and_drop() into
> static void check_and_drop(void *_data)
> {
> struct detach_data *data = _data;
>
> if (!data->mountpoint && list_empty(&data->select.dispose))
> __d
Hi Shaohua,
[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on v4.12-rc3 next-20170602]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Shaohua-Li/kernfs
On Mon, May 29, 2017 at 6:00 PM, Christophe LEROY
wrote:
>
>
> Le 25/05/2017 à 18:45, kbuild test robot a écrit :
>>
>> Hi Balbir,
>>
>> [auto build test ERROR on powerpc/next]
>> [also build test ERROR on v4.12-rc2 next-20170525]
>> [if your patch is applied to the wrong git tree, please drop us
This patch was modified from Brad Spengler's Trusted Path Execution (TPE)
feature in Grsecurity and also incorporates logging ideas from
cormander's tpe-lkm.
Modifications from the Grsecurity implementation of TPE were made to
turn it into a stackable LSM using the existing LSM hook bprm_set_creds
No comments for this series? Everything fine? Has it been merged somewhere?
> Am 21.05.2017 um 12:38 schrieb H. Nikolaus Schaller :
>
> Changes V5:
> * reworked max_current removal patch (comments by Sebastian Reichel)
> * resubmit missing madc connection for AC power detection
> * resubmit patch
Hi Ding,
[auto build test WARNING on pci/next]
[cannot apply to v4.12-rc3 next-20170602]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ding-Tianhong/Add-new-PCI_DEV_FLAGS_NO_RELAXED_ORDERING
On Fri, 2 Jun 2017 16:15:00 -0400
Don Zickus wrote:
> On Tue, May 30, 2017 at 11:26:58AM +1000, Nicholas Piggin wrote:
> > Split SOFTLOCKUP_DETECTOR from LOCKUP_DETECTOR, and split
> > HARDLOCKUP_DETECTOR_PERF from HARDLOCKUP_DETECTOR.
> >
> > LOCKUP_DETECTOR provides the boot, sysctl, and progr
On Fri, Jun 02, 2017 at 10:22:39PM -0700, Khazhismel Kumykov wrote:
> On Fri, Jun 2, 2017 at 6:12 PM, Al Viro wrote:
> > Part of that could be relieved if we turned check_and_drop() into
> > static void check_and_drop(void *_data)
> > {
> > struct detach_data *data = _data;
> >
> >
On Sat, Jun 03, 2017 at 01:53:51AM -0400, Matt Brown wrote:
> +static int tpe_bprm_set_creds(struct linux_binprm *bprm)
> +{
> + struct file *file = bprm->file;
> + struct inode *inode = d_backing_inode(file->f_path.dentry->d_parent);
> + struct inode *file_inode = d_backing_inode(file
On Wed, 2017-05-31 at 13:21 -0400, Dave Jones wrote:
> Just hit this during a trinity run.
925bb1ce47f429f69aad35876df7ecd8c53deb7e is the first bad commit
commit 925bb1ce47f429f69aad35876df7ecd8c53deb7e
Author: Vegard Nossum
Date: Thu May 11 12:18:52 2017 +0200
tty: fix port buffer lockin
On Fri, Jun 2, 2017 at 11:20 PM, Al Viro wrote:
> The thing is, unlike shrink_dcache_parent() we *can* bugger off as
> soon as we'd found no victims, nothing mounted and dentry itself
> is unhashed. We can't do anything in select_collect() (we would've
> broken shrink_dcache_parent() that way), b
On Sat, 3 Jun 2017 04:57:21 +0800
kbuild test robot wrote:
> Hi Nicholas,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.12-rc3 next-20170602]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system
801 - 824 of 824 matches
Mail list logo
