On Thu, 26 Feb 2009, Mark Nelson wrote:
> On Thu, 26 Feb 2009 09:45:41 am Mark Nelson wrote:
> > On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote:
> > > On Wed, 25 Feb 2009, Mark Nelson wrote:
> > > > Does the following patch fix the errors you're seeing? (it applies the
> > > > same fix as
On Thu, 26 Feb 2009 09:45:41 am Mark Nelson wrote:
> On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote:
> > On Wed, 25 Feb 2009, Mark Nelson wrote:
> > > On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
> > > > On Wed, 25 Feb 2009, Mark Nelson wrote:
> > > > > On Tue, 24 Feb 2009 05
On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote:
> On Wed, 25 Feb 2009, Mark Nelson wrote:
> > On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
> > > On Wed, 25 Feb 2009, Mark Nelson wrote:
> > > > On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
> > > > > Jan Kara wrote:
> >
On Wed, 25 Feb 2009, Mark Nelson wrote:
> On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
> > On Wed, 25 Feb 2009, Mark Nelson wrote:
> > > On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
> > > > Jan Kara wrote:
> > > > > Hmm, OK. But then I'm not sure how that can happen. Obvious
On Wed, 25 Feb 2009 10:08:22 pm Sachin P. Sant wrote:
> Mark Nelson wrote:
> > Hi Sanchin and Geert,
> >
> > Does the patch below fix the problems you're seeing? If it does I'll send
> > a properly written up and formatted patch to linuxppc-dev (as well as
> > another one to fix the same problem in
On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
> On Wed, 25 Feb 2009, Mark Nelson wrote:
> > On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
> > > Jan Kara wrote:
> > > > Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> > > > somehow got beyond end of the p
Mark Nelson wrote:
Hi Sanchin and Geert,
Does the patch below fix the problems you're seeing? If it does I'll send
a properly written up and formatted patch to linuxppc-dev (as well as
another one to fix the same problem in copy_tofrom_user()).
This patch fixes the issue at my side. I tried
On Wed, 25 Feb 2009, Mark Nelson wrote:
> On Wed, 25 Feb 2009 05:01:59 am Geert Uytterhoeven wrote:
> > On Mon, 23 Feb 2009, Paul Mackerras wrote:
> > > Andrew Morton writes:
> > > > It looks like we died in ext3_xattr_block_get():
> > > >
> > > > memcpy(buffer, bh->b_data +
> > >
On Wed, 25 Feb 2009, Mark Nelson wrote:
> On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
> > Jan Kara wrote:
> > > Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> > > somehow got beyond end of the page referenced by bh->b_data. So it means
> > > that le16_to_cpu(ent
On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
> Jan Kara wrote:
> > Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> > somehow got beyond end of the page referenced by bh->b_data. So it means
> > that le16_to_cpu(entry->e_value_offs) + size > page_size. But
> > ext3
On Wed, 25 Feb 2009 05:01:59 am Geert Uytterhoeven wrote:
> On Mon, 23 Feb 2009, Paul Mackerras wrote:
> > Andrew Morton writes:
> > > It looks like we died in ext3_xattr_block_get():
> > >
> > > memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> > > size);
On Wed, 25 Feb 2009 02:51:20 am Jan Kara wrote:
> Hello,
>
> On Tue 24-02-09 12:08:37, Sachin P. Sant wrote:
> > Jan Kara wrote:
> >> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> >> somehow got beyond end of the page referenced by bh->b_data. So it means
> >> that le
On Mon, 23 Feb 2009, Paul Mackerras wrote:
> Andrew Morton writes:
> > It looks like we died in ext3_xattr_block_get():
> >
> > memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> >size);
> >
> > Perhaps entry->e_value_offs is no good. I wonder if the
> Andrew Morton wrote:
> >hm, I wonder what could have caused that - we haven't altered
> >fs/ext3/xattr.c in ages.
> >
> >What is the most recent kernel version you know of which didn't do
> >this? Bear in mind that this crash might be triggered by the
> >current contents of the filesystem, so if
Hello,
On Tue 24-02-09 12:08:37, Sachin P. Sant wrote:
> Jan Kara wrote:
>> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
>> somehow got beyond end of the page referenced by bh->b_data. So it means
>> that le16_to_cpu(entry->e_value_offs) + size > page_size. But
>> ext3
Jan Kara wrote:
Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
somehow got beyond end of the page referenced by bh->b_data. So it means
that le16_to_cpu(entry->e_value_offs) + size > page_size. But
ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in
particular
> Andrew Morton writes:
>
> > It looks like we died in ext3_xattr_block_get():
> >
> > memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> >size);
> >
> > Perhaps entry->e_value_offs is no good. I wonder if the filesystem is
> > corrupted and this snu
Paul Mackerras wrote:
It appears to have faulted on a load, implicating the source. The
address being referenced (0xc0003f38) doesn't look
outlandish. I wonder if this kernel has CONFIG_DEBUG_PAGEALLOC turned
on, and what page size is selected?
Yes CONFIG_DEBUG_PAGEALLOC is enabled and
Andrew Morton wrote:
hm, I wonder what could have caused that - we haven't altered
fs/ext3/xattr.c in ages.
What is the most recent kernel version you know of which didn't do
this? Bear in mind that this crash might be triggered by the
current contents of the filesystem, so if possible, please
Andrew Morton writes:
> It looks like we died in ext3_xattr_block_get():
>
> memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> size);
>
> Perhaps entry->e_value_offs is no good. I wonder if the filesystem is
> corrupted and this snuck through the
On Mon, 23 Feb 2009 15:16:05 +0530 "Sachin P. Sant" wrote:
> 2.6.29-rc6 bootup on a powerpc box failed with
>
> Unable to handle kernel paging request for data at address 0xc0003f38
> Faulting instruction address: 0xc0039574
> cpu 0x1: Vector: 300 (Data Access) at [c0003baf30
21 matches
Mail list logo