On Tue, Oct 16, 2012 at 8:12 PM, David Rientjes wrote:
> On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
>
>> >> Even though 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a itself is simple. It
>> >> bring
>> >> to caller complex. That's not good and have no worth.
>> >>
>> >
>> > Before: the kernel panics,
On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
> >> Even though 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a itself is simple. It
> >> bring
> >> to caller complex. That's not good and have no worth.
> >>
> >
> > Before: the kernel panics, all workloads cease.
> > After: the file shows garbage, all work
On Tue, Oct 16, 2012 at 2:10 AM, David Rientjes wrote:
> On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
>
>> >> I don't think 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a is right fix.
>> >
>> > It's certainly not a complete fix, but I think it's a much better result
>> > of the race, i.e. we don't panic
On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
> >> I don't think 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a is right fix.
> >
> > It's certainly not a complete fix, but I think it's a much better result
> > of the race, i.e. we don't panic anymore, we simply fail the read()
> > instead.
>
> Even thou
On Mon, Oct 15, 2012 at 11:58 PM, David Rientjes wrote:
> On Mon, 15 Oct 2012, KOSAKI Motohiro wrote:
>
>> I don't think 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a is right fix.
>
> It's certainly not a complete fix, but I think it's a much better result
> of the race, i.e. we don't panic anymore, w
On Mon, 15 Oct 2012, KOSAKI Motohiro wrote:
> I don't think 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a is right fix.
It's certainly not a complete fix, but I think it's a much better result
of the race, i.e. we don't panic anymore, we simply fail the read()
instead.
> we should
> close a race (o
On Mon, 8 Oct 2012, Dave Jones wrote:
> > > diff -durpN '--exclude-from=/home/davej/.exclude'
> src/git-trees/kernel/linux/fs/proc/task_mmu.c linux-dj/fs/proc/task_mmu.c
> > > --- src/git-trees/kernel/linux/fs/proc/task_mmu.c2012-05-31
> 22:32:46.778150675 -0400
> > > +++ linux-dj/fs/
On Mon, 2012-10-08 at 11:09 -0400, Dave Jones wrote:
> Last month I sent in 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a to remove
> a user triggerable BUG in mempolicy.
>
> Ben Hutchings pointed out to me that my change introduced a potential leak
> of stack contents to userspace, because none of the
On Mon, Oct 08, 2012 at 01:35:42PM -0700, David Rientjes wrote:
> > unanswered question: why are the buffer sizes here different ? which is
> > correct?
> >
> Given the current set of mempolicy modes and flags, it's 34, but this can
> change if new modes or flags are added with longer name
On Mon, 8 Oct 2012, Dave Jones wrote:
> unanswered question: why are the buffer sizes here different ? which is
> correct?
>
Given the current set of mempolicy modes and flags, it's 34, but this can
change if new modes or flags are added with longer names. I see no reason
why shmem shouldn't
On Mon, Oct 08, 2012 at 11:09:49AM -0400, Dave Jones wrote:
> Last month I sent in 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a to remove
> a user triggerable BUG in mempolicy.
>
> Ben Hutchings pointed out to me that my change introduced a potential leak
> of stack contents to userspace, because
Last month I sent in 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a to remove
a user triggerable BUG in mempolicy.
Ben Hutchings pointed out to me that my change introduced a potential leak
of stack contents to userspace, because none of the callers check the return
value.
This patch adds the missing
12 matches
Mail list logo
