On Thu, Jul 08, 2010 at 06:04:31PM +0200, Marc Olzheim wrote:
> On Thu, Jul 08, 2010 at 11:03:18AM +0300, Eugene Perevyazko wrote:
> > I have this problem on 7.2-S for pretty long time. But as I sendfile() very
> > small file (several hundred bytes) from flash I was blaming faulty flash
> > stick
On Thu, Jul 08, 2010 at 11:03:18AM +0300, Eugene Perevyazko wrote:
> I have this problem on 7.2-S for pretty long time. But as I sendfile() very
> small file (several hundred bytes) from flash I was blaming faulty flash
> stick.
> I've even made a crontab entry to replace corrupted file.
> So the
on 08/07/2010 14:47 Kostik Belousov said the following:
> - n->m_flags |= M_EXT;
> + n->m_flags |= M_EXT | m->m_flags;
BTW, I think that M_EXT must already be in m->m_flags if mb_dupcl() is called.
--
Andriy Gapon
___
freebsd-net@freebsd.org ma
On Thu, Jul 08, 2010 at 01:58:50PM +0200, Andre Oppermann wrote:
> On 08.07.2010 13:47, Kostik Belousov wrote:
> >On Thu, Jul 08, 2010 at 01:34:28PM +0200, Andre Oppermann wrote:
> >>On 08.07.2010 11:42, Kostik Belousov wrote:
> >>>On Thu, Jul 08, 2010 at 11:40:05AM +0300, Andriy Gapon wrote:
> >>>
On 08.07.2010 13:47, Kostik Belousov wrote:
On Thu, Jul 08, 2010 at 01:34:28PM +0200, Andre Oppermann wrote:
On 08.07.2010 11:42, Kostik Belousov wrote:
On Thu, Jul 08, 2010 at 11:40:05AM +0300, Andriy Gapon wrote:
on 08/07/2010 11:29 Kostik Belousov said the following:
Right, the patch maps
On Thu, Jul 08, 2010 at 01:34:28PM +0200, Andre Oppermann wrote:
> On 08.07.2010 11:42, Kostik Belousov wrote:
> >On Thu, Jul 08, 2010 at 11:40:05AM +0300, Andriy Gapon wrote:
> >>on 08/07/2010 11:29 Kostik Belousov said the following:
> >>>Right, the patch maps the page in sf buffer read-only (on
On 08.07.2010 11:42, Kostik Belousov wrote:
On Thu, Jul 08, 2010 at 11:40:05AM +0300, Andriy Gapon wrote:
on 08/07/2010 11:29 Kostik Belousov said the following:
Right, the patch maps the page in sf buffer read-only (on i386 only).
But note the parallel posting with m_cat() change. It is still
on 08/07/2010 12:40 Andriy Gapon said the following:
> on 08/07/2010 11:40 Andriy Gapon said the following:
>> on 08/07/2010 11:29 Kostik Belousov said the following:
>>> Right, the patch maps the page in sf buffer read-only (on i386 only).
>>> But note the parallel posting with m_cat() change. It
on 08/07/2010 11:40 Andriy Gapon said the following:
> on 08/07/2010 11:29 Kostik Belousov said the following:
>> Right, the patch maps the page in sf buffer read-only (on i386 only).
>> But note the parallel posting with m_cat() change. It is still not enough,
>> and I am not set up for the real n
On Thu, Jul 08, 2010 at 11:40:05AM +0300, Andriy Gapon wrote:
> on 08/07/2010 11:29 Kostik Belousov said the following:
> > Right, the patch maps the page in sf buffer read-only (on i386 only).
> > But note the parallel posting with m_cat() change. It is still not enough,
> > and I am not set up fo
on 08/07/2010 11:29 Kostik Belousov said the following:
> Right, the patch maps the page in sf buffer read-only (on i386 only).
> But note the parallel posting with m_cat() change. It is still not enough,
> and I am not set up for the real network testing ATM.
Could you also try to experiment with
On Thu, Jul 08, 2010 at 11:19:13AM +0300, Andriy Gapon wrote:
> on 08/07/2010 11:11 Andre Oppermann said the following:
> >
> > Can you check whether your patch fixes the bug when you go over a real
> > network?
>
> As I understand the patch is not supposed to fix the bug, it's supposed to
> cat
On Thu, Jul 08, 2010 at 10:51:21AM +0300, Andriy Gapon wrote:
>
> Not an expert by any measure but the following looks suspicious:
> m_copy/m_copym calls mb_dupcl for M_EXT case and M_RDONLY is _not_ checked nor
> preserved in that case.
> So we may get a writable M_EXT mbuf pointing to sf_buf wra
on 08/07/2010 11:11 Andre Oppermann said the following:
>
> Can you check whether your patch fixes the bug when you go over a real
> network?
As I understand the patch is not supposed to fix the bug, it's supposed to catch
it early. I.e. get panic instead of data corruption.
--
Andriy Gapon
__
On 07.07.2010 22:50, Kostik Belousov wrote:
On Wed, Jul 07, 2010 at 10:24:41AM -0700, Ming Fu wrote:
Hi,
I was trying to use sendfile and hit with problem very similar to the
123095 and 131602.
It seems that when the file is large enough (in megs), the file can be
corrupted even if it is open
On Wed, Jul 07, 2010 at 10:24:41AM -0700, Ming Fu wrote:
> Hi,
>
>
> I was trying to use sendfile and hit with problem very similar to the
> 123095 and 131602.
> It seems that when the file is large enough (in megs), the file can be
> corrupted even if it is open read-only and exist on disk as r
Not an expert by any measure but the following looks suspicious:
m_copy/m_copym calls mb_dupcl for M_EXT case and M_RDONLY is _not_ checked nor
preserved in that case.
So we may get a writable M_EXT mbuf pointing to sf_buf wrapping a page of a
file.
But I am not sure if/how mbufs are re-used and
on 07/07/2010 20:24 Ming Fu said the following:
> flags = fcntl(s, F_GETFL);
> flags |= O_NONBLOCK;
> fcntl(s, F_SETFL);
Seems like flags parameter is missing in the last call.
That shouldn't trigger the bug though.
--
Andriy Gapon
On Wed, Jul 07, 2010 at 10:24:41AM -0700, Ming Fu wrote:
> Hi,
>
>
> I was trying to use sendfile and hit with problem very similar to the
> 123095 and 131602.
> It seems that when the file is large enough (in megs), the file can be
> corrupted even if it is open read-only and exist on disk as r
19 matches
Mail list logo
