From: Linus Torvalds
> Sent: 24 August 2019 21:57
> On Sat, Aug 24, 2019 at 1:22 PM Ingo Molnar wrote:
> >
> > That makes sense: I measured 17 seconds per 100 MB of data, which is is
> > 0.16 usecs per byte. The instruction used by
> > copy_user_enhanced_fast_string() is REP MOVSB - which
* Tetsuo Handa wrote:
> On 2019/08/26 1:54, Linus Torvalds wrote:
> > On Sat, Aug 24, 2019 at 10:50 PM Tetsuo Handa
> > wrote:
> >>
> >> @@ -142,7 +144,7 @@ static ssize_t read_mem(struct file *file, char __user
> >> *buf,
> >> sz = size_inside_page(p, count);
> >>
On 2019/08/26 1:54, Linus Torvalds wrote:
> On Sat, Aug 24, 2019 at 10:50 PM Tetsuo Handa
> wrote:
>>
>> @@ -142,7 +144,7 @@ static ssize_t read_mem(struct file *file, char __user
>> *buf,
>> sz = size_inside_page(p, count);
>> cond_resched();
>>
On Sat, Aug 24, 2019 at 10:50 PM Tetsuo Handa
wrote:
>
> @@ -142,7 +144,7 @@ static ssize_t read_mem(struct file *file, char __user
> *buf,
> sz = size_inside_page(p, count);
> cond_resched();
> err = -EINTR;
> - if
* Tetsuo Handa wrote:
> > - We should probably separate out a third 'fatal error' variant: for
> >example if copying to user-space generates a page fault, then we
> >clearly should not pretend that all is fine and return a short read
> >even if we made some progress, a -EFAULT
On 2019/08/25 18:59, Ingo Molnar wrote:
>> @@ -132,8 +132,10 @@ static ssize_t read_mem(struct file *file, char __user
>> *buf,
>> #endif
>>
>> bounce = kmalloc(PAGE_SIZE, GFP_KERNEL);
>> -if (!bounce)
>> -return -ENOMEM;
>> +if (!bounce) {
>> +err =
* Tetsuo Handa wrote:
> On 2019/08/25 5:22, Ingo Molnar wrote:
> >> So I'd be willing to try that (and then if somebody reports a
> >> regression we can make it use "fatal_signal_pending()" instead)
> >
> > Ok, will post a changelogged patch (unless Tetsuo beats me to it?).
>
> Here is a
On 2019/08/25 5:22, Ingo Molnar wrote:
>> So I'd be willing to try that (and then if somebody reports a
>> regression we can make it use "fatal_signal_pending()" instead)
>
> Ok, will post a changelogged patch (unless Tetsuo beats me to it?).
Here is a patch. This patch also tries to fix
On Sat, Aug 24, 2019 at 1:22 PM Ingo Molnar wrote:
>
> That makes sense: I measured 17 seconds per 100 MB of data, which is is
> 0.16 usecs per byte. The instruction used by
> copy_user_enhanced_fast_string() is REP MOVSB - which supposedly goes as
> high as cacheline size accesses - but perhaps
* Linus Torvalds wrote:
> On Sat, Aug 24, 2019 at 9:14 AM Ingo Molnar wrote:
> >
> > What I noticed is that while reading regular RAM is reasonably fast even
> > in very large chunks, accesses become very slow once they hit iomem - and
> > delays even longer than the reported 145 seconds
On Sat, Aug 24, 2019 at 9:14 AM Ingo Molnar wrote:
>
> What I noticed is that while reading regular RAM is reasonably fast even
> in very large chunks, accesses become very slow once they hit iomem - and
> delays even longer than the reported 145 seconds become possible if
> bs=100M is increased
* Linus Torvalds wrote:
> On Fri, Aug 23, 2019 at 2:16 AM Ingo Molnar wrote:
> >
> > > + */
> > > + if (fatal_signal_pending(current)) {
> > > + if (!(error_code & X86_PF_USER))
> > > + no_context(regs, error_code, address, 0, 0);
> >
> > Since the
On Fri, Aug 23, 2019 at 1:17 AM Tetsuo Handa
wrote:
>
> On 2019/08/23 8:59, Dmitry Vyukov wrote:
> >> Can't we introduce a kernel config which selectively blocks specific
> >> actions?
> >> If we don't need to worry about bypassing blacklist checks, we will be
> >> able to
> >> enable
On Fri, Aug 23, 2019 at 2:16 AM Ingo Molnar wrote:
>
> > + */
> > + if (fatal_signal_pending(current)) {
> > + if (!(error_code & X86_PF_USER))
> > + no_context(regs, error_code, address, 0, 0);
>
> Since the 'signal' parameter to no_context() is 0, will
On 2019/08/23 7:08, Linus Torvalds wrote:
>> syzbot found that a thread can stall for minutes inside read_mem()
>> after that thread was killed by SIGKILL [1]. Reading 2GB at one read()
>> is legal, but delaying termination of killed thread for minutes is bad.
>
> Side note: we might even just
* Linus Torvalds wrote:
> On Tue, Aug 20, 2019 at 3:07 PM Tetsuo Handa
> wrote:
> >
> > syzbot found that a thread can stall for minutes inside read_mem()
> > after that thread was killed by SIGKILL [1]. Reading 2GB at one read()
> > is legal, but delaying termination of killed thread for
On 2019/08/23 8:59, Dmitry Vyukov wrote:
>> Can't we introduce a kernel config which selectively blocks specific actions?
>> If we don't need to worry about bypassing blacklist checks, we will be able
>> to
>> enable syz_execute_func() again.
>
>
> We can consider this, but we need some set of
On Thu, Aug 22, 2019 at 2:17 PM Tetsuo Handa
wrote:
>
> On 2019/08/23 2:11, Dmitry Vyukov wrote:
> > On Thu, Aug 22, 2019 at 9:42 AM Greg Kroah-Hartman
> > wrote:
> > By the way, write_mem() worries me whether there is possibility of
> > replacing
> > kernel code/data with
On Tue, Aug 20, 2019 at 3:07 PM Tetsuo Handa
wrote:
>
> syzbot found that a thread can stall for minutes inside read_mem()
> after that thread was killed by SIGKILL [1]. Reading 2GB at one read()
> is legal, but delaying termination of killed thread for minutes is bad.
Side note: we might even
On Tue, Aug 20, 2019 at 3:07 PM Tetsuo Handa
wrote:
>
> - while (count > 0) {
> + while (count > 0 && !fatal_signal_pending(current)) {
Please just use the normal pattern of doing
if (fatal_signal_pending(current))
return -EINTR;
inside the loop instead.
On 2019/08/23 2:11, Dmitry Vyukov wrote:
> On Thu, Aug 22, 2019 at 9:42 AM Greg Kroah-Hartman
> wrote:
> By the way, write_mem() worries me whether there is possibility of
> replacing
> kernel code/data with user-defined memory data supplied from userspace.
> If write_mem() were
On Thu, Aug 22, 2019 at 9:42 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Aug 22, 2019 at 11:00:59PM +0900, Tetsuo Handa wrote:
> > On 2019/08/22 22:35, Greg Kroah-Hartman wrote:
> > > On Thu, Aug 22, 2019 at 06:59:25PM +0900, Tetsuo Handa wrote:
> > >> Tetsuo Handa wrote:
> > >>> Greg Kroah-Hartman
On Thu, Aug 22, 2019 at 11:00:59PM +0900, Tetsuo Handa wrote:
> On 2019/08/22 22:35, Greg Kroah-Hartman wrote:
> > On Thu, Aug 22, 2019 at 06:59:25PM +0900, Tetsuo Handa wrote:
> >> Tetsuo Handa wrote:
> >>> Greg Kroah-Hartman wrote:
> Oh, nice! This shouldn't break anything that is assuming
On 2019/08/22 22:35, Greg Kroah-Hartman wrote:
> On Thu, Aug 22, 2019 at 06:59:25PM +0900, Tetsuo Handa wrote:
>> Tetsuo Handa wrote:
>>> Greg Kroah-Hartman wrote:
Oh, nice! This shouldn't break anything that is assuming that the read
will complete before a signal is delivered, right?
On Thu, Aug 22, 2019 at 06:59:25PM +0900, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Greg Kroah-Hartman wrote:
> > > Oh, nice! This shouldn't break anything that is assuming that the read
> > > will complete before a signal is delivered, right?
> > >
> > > I know userspace handling of "short"
Tetsuo Handa wrote:
> Greg Kroah-Hartman wrote:
> > Oh, nice! This shouldn't break anything that is assuming that the read
> > will complete before a signal is delivered, right?
> >
> > I know userspace handling of "short" reads is almost always not there...
>
> Since this check will give up
Greg Kroah-Hartman wrote:
> Oh, nice! This shouldn't break anything that is assuming that the read
> will complete before a signal is delivered, right?
>
> I know userspace handling of "short" reads is almost always not there...
Since this check will give up upon SIGKILL, userspace won't be able
On Wed, Aug 21, 2019 at 07:06:51AM +0900, Tetsuo Handa wrote:
> syzbot found that a thread can stall for minutes inside read_mem()
> after that thread was killed by SIGKILL [1]. Reading 2GB at one read()
> is legal, but delaying termination of killed thread for minutes is bad.
>
> [
syzbot found that a thread can stall for minutes inside read_mem()
after that thread was killed by SIGKILL [1]. Reading 2GB at one read()
is legal, but delaying termination of killed thread for minutes is bad.
[ 1335.912419][T20577] read_mem: sz=4096 count=2134565632
[ 1335.943194][T20577]
29 matches
Mail list logo
