On Mar,Tuesday 23 2010, at 4:09 PM, Jonathan A. Kollasch wrote:
> Module Name: src
> Committed By: jakllsch
> Date: Tue Mar 23 15:09:45 UTC 2010
>
> Modified Files:
> src/sys/dev/dm: device-mapper.c
>
> Log Message:
> Rework module/builtin code so it works in both cases.
> (Teste
On Tue, Mar 23, 2010 at 04:24:06PM +, David Holland wrote:
> On Sat, Mar 20, 2010 at 11:31:31PM +, Chuck Silvers wrote:
> > fix copy{in,out}{,str}() to return the error returned by uvm_fault().
> > fixes PR 41813.
>
> Do you know if/how this will affect PR 11904? What happens now on EIO
> Modified Files:
> src/lib/libpthread: pthread.c
>
> Log Message:
> fix the pthread pt_lid in the fork callback function that runs in the child=
> instead of a function that may be going away. KNFify
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.114 -r1.115 src/lib/libpthr
On Wed, Mar 24, 2010 at 06:41:38AM -0700, Chuck Silvers wrote:
> > > fix copy{in,out}{,str}() to return the error returned by uvm_fault().
> > > fixes PR 41813.
> >
> > Do you know if/how this will affect PR 11904? What happens now on EIO
> > in a memory-mapped file?
>
> this change doesn'
On Thu, Mar 25, 2010 at 04:57:27AM +, David Holland wrote:
> Well... yes, but I guess I don't understand how the read() in the PR
> would end up trapping in copyin/copyout. Presumably there's a uiomove
> in there somewhere, but I would have thought it wouldn't reach it at
> all if the I/O faile
On Thu, Mar 25, 2010 at 02:20:42PM +0900, Masao Uebayashi wrote:
> ubc_alloc()
> ubc_uiomove()
Actually this should have been:
ufs_read()
ubc_alloc()
ubc_uiomove()
...
ubc_alloc() prepares UBC context before fault.
Masao
--
Masao Uebayashi
