On Thu, Jun 10, 2010 at 07:30:45PM +0300, Modestas Vainius wrote:
> Hello,
>
> On sekmadienis 06 Bir??elis 2010 04:01:23 Modestas Vainius wrote:
> > On penktadienis 04 Bir??elis 2010 08:21:06 dann frazier wrote:
> > > > My case and my analysis talked about UP kernel, and John David Anglin
> > > >
Hello,
On sekmadienis 06 Birželis 2010 04:01:23 Modestas Vainius wrote:
> On penktadienis 04 Birželis 2010 08:21:06 dann frazier wrote:
> > > My case and my analysis talked about UP kernel, and John David Anglin
> > >
> > > made a patch:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=56
On Fri, Jun 04, 2010 at 12:44:55PM +0200, Thibaut VARENE wrote:
> On Fri, Jun 4, 2010 at 7:21 AM, dann frazier wrote:
> > On Fri, Jun 04, 2010 at 10:03:07AM +0900, NIIBE Yutaka wrote:
> >> Modestas Vainius wrote:
> Note that Debian's buildds run a UP kernel, so as soon as those fixes
> g
Hello,
On penktadienis 04 Birželis 2010 08:21:06 dann frazier wrote:
> > My case and my analysis talked about UP kernel, and John David Anglin
> >
> > made a patch:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203#144
> >
> > After that, the discussion went to SMP cases.
> >
> >
On Fri, Jun 4, 2010 at 7:21 AM, dann frazier wrote:
> On Fri, Jun 04, 2010 at 10:03:07AM +0900, NIIBE Yutaka wrote:
>> Modestas Vainius wrote:
Note that Debian's buildds run a UP kernel, so as soon as those fixes
go upstream we can pull them in. Thanks for all your work here!
>>>
>>
severity 561203 serious
thanks
On Thu, Jun 03, 2010 at 11:50:05AM +0300, Modestas Vainius wrote:
> # Breaks unrelated applications
Sorry, no. Almost all applications are related to the kernel.
> Well, as long as this is unfixed or at least "common", I don't see how hppa
> can be considered to b
On Fri, Jun 04, 2010 at 10:03:07AM +0900, NIIBE Yutaka wrote:
> Modestas Vainius wrote:
>>> Note that Debian's buildds run a UP kernel, so as soon as those fixes
>>> go upstream we can pull them in. Thanks for all your work here!
>>>
>>
>> Well, as long as this is unfixed or at least "common", I do
Modestas Vainius wrote:
Note that Debian's buildds run a UP kernel, so as soon as those fixes
go upstream we can pull them in. Thanks for all your work here!
Well, as long as this is unfixed or at least "common", I don't see how hppa
can be considered to be a release arch. Is that UP patch ava
# Breaks unrelated applications
tags 561203 critical
thanks
Hello,
On trečiadienis 02 Birželis 2010 20:56:17 dann frazier wrote:
> On Wed, Jun 02, 2010 at 01:16:01PM -0400, John David Anglin wrote:
> > On Wed, 02 Jun 2010, Modestas Vainius wrote:
> > > Hello,
> > >
> > > this bug [1] is back to
On Wed, Jun 02, 2010 at 01:16:01PM -0400, John David Anglin wrote:
> On Wed, 02 Jun 2010, Modestas Vainius wrote:
>
> > Hello,
> >
> > this bug [1] is back to the "very common" department with eglibc 2.11
> > (libc6-
> > dev_2.11.1-1) builds. Majority of KDE applications are failing to build on
On Wed, 02 Jun 2010, Modestas Vainius wrote:
> Hello,
>
> this bug [1] is back to the "very common" department with eglibc 2.11 (libc6-
> dev_2.11.1-1) builds. Majority of KDE applications are failing to build on
> hppa again. Is there really nothing what could be done to fix it?
I will just sa
Hello,
this bug [1] is back to the "very common" department with eglibc 2.11 (libc6-
dev_2.11.1-1) builds. Majority of KDE applications are failing to build on
hppa again. Is there really nothing what could be done to fix it?
1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203
2.
https:/
> On Thu, 08 Apr 2010, Helge Deller wrote:
> > I tested your patch today on one of my machines with plain kernel 2.6.33
> > (32bit, SMP, B2000 I think).
> > Sadly I still did see the minifail bug.
> >
> > Are you sure, that the patch fixed this bug for you?
>
> Seemed to, but I have a bunch of
On Thu, 08 Apr 2010, Helge Deller wrote:
> On 04/02/2010 09:35 PM, John David Anglin wrote:
> > On Fri, 02 Apr 2010, NIIBE Yutaka wrote:
> >
> >> NIIBE Yutaka wrote:
> >>> To have same semantics as other archs, I think that VIPT-WB cache
> >>> machine should have cache flush at ptep_set_wrprotect
On 04/02/2010 09:35 PM, John David Anglin wrote:
> On Fri, 02 Apr 2010, NIIBE Yutaka wrote:
>
>> NIIBE Yutaka wrote:
>>> To have same semantics as other archs, I think that VIPT-WB cache
>>> machine should have cache flush at ptep_set_wrprotect, so that memory
>>> of the page has up-to-date data.
On Tue, 2010-04-06 at 13:57 +0900, NIIBE Yutaka wrote:
> John David Anglin wrote:
> > It is interesting that in the case of the Debian bug that
> > a thread of the parent process causes the COW break and thereby corrupts
> > its own memory. As far as I can tell, the fork'd child never writes
> > t
On Tue, 2010-04-06 at 08:37 -0500, James Bottomley wrote:
> > (5) Child process B is waken up and sees old value at in
> ,
> > through different cache line. B sleeps.
>
> This isn't possible. at this point, A and B have the same virtual
> address and mapping for this means they are the sam
John David Anglin wrote:
> It is interesting that in the case of the Debian bug that
> a thread of the parent process causes the COW break and thereby corrupts
> its own memory. As far as I can tell, the fork'd child never writes
> to the memory that causes the fault.
Thanks for writing and testi
On Sun, 2010-04-04 at 22:51 -0400, John David Anglin wrote:
> > Thanks a lot for the discussion.
> >
> > James Bottomley wrote:
> > > So your theory is that the data the kernel sees doing the page copy can
> > > be stale because of dirty cache lines in userspace (which is certainly
> > > possible
> > > By design that shouldn't happen: the idea behind COW breaking is
> > > that before it breaks, the page is read only ... this means that
> > > processes can have clean cache copies of it, but never dirty cache
> > > copies (because writes are forbidden).
> >
> > That must be design, I agree.
> Thanks a lot for the discussion.
>
> James Bottomley wrote:
> > So your theory is that the data the kernel sees doing the page copy can
> > be stale because of dirty cache lines in userspace (which is certainly
> > possible in the ordinary way)?
>
> Yes.
>
> > By design that shouldn't happen:
retitle 561203 threads and fork on machine with VIPT-WB cache
reassign 561203 linux-2.6
thanks
As I am sure that this bug lives in kernel, I do reassign and retitle.
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list
Thanks a lot for the discussion.
James Bottomley wrote:
> So your theory is that the data the kernel sees doing the page copy can
> be stale because of dirty cache lines in userspace (which is certainly
> possible in the ordinary way)?
Yes.
> By design that shouldn't happen: the idea behind COW
On Fri, 02 Apr 2010, NIIBE Yutaka wrote:
> NIIBE Yutaka wrote:
>> To have same semantics as other archs, I think that VIPT-WB cache
>> machine should have cache flush at ptep_set_wrprotect, so that memory
>> of the page has up-to-date data. Yes, it will be huge performance
>> impact for fork. Bu
On Fri, 2010-04-02 at 12:48 +0900, NIIBE Yutaka wrote:
> Thanks for your quick reply.
>
> James Bottomley wrote:
> > In COW breaking, the page table entry is copied, so A and B no longer
> > have page table entries at the same physical location. If the COW is
> > intact, A and B have the same phy
NIIBE Yutaka wrote:
To have same semantics as other archs, I think that VIPT-WB cache
machine should have cache flush at ptep_set_wrprotect, so that memory
of the page has up-to-date data. Yes, it will be huge performance
impact for fork. But I don't find any good solution other than this
yet.
Thanks for your quick reply.
James Bottomley wrote:
> In COW breaking, the page table entry is copied, so A and B no longer
> have page table entries at the same physical location. If the COW is
> intact, A and B have the same physical page, but it's also accessed by
> the same virtual address, h
On Fri, 2010-04-02 at 11:41 +0900, NIIBE Yutaka wrote:
> (9) Process B does read-access on memory, which gets *NEW* data in
> cache (if process space identifier color is same).
> Process B does write-access on memory which causes memory fault,
> as it's COW memory.
>
> Note: Proces
Hi there,
I think that I am catching a bug for threads and fork. I found it
when debugging FTBFS of Gauche, a Scheme interpreter. As I think that
the Debian bug #561203 has same cause, I am CC:-ing to the BTS too.
Please send Cc: to me, I am not on linux-parisc list.
Here, I am talking uniproce
29 matches
Mail list logo
