On Tue, 30 May 2000, Alexander Viro wrote:
>
>
> On Wed, 31 May 2000, Khimenko Victor wrote:
>
> > In <Pine.GSO.4.10.10005301705460.17448-100000@weyl.math.psu.edu> Alexander Viro (viro@math.psu.edu) wrote:
> >
> >
> > AV> On Wed, 31 May 2000, Chris Wedgwood wrote:
> >
> > >> On Sun, May 28, 2000 at 01:46:01PM +0400, Khimenko Victor wrote:
> > >>
> > >> So it's not just me. Is it known issue ? Even if locking on unix
> > >> sockets is not supported (why?) kernel oops and segmentation
> > >> fault does not look like right rection to me :-/
> > >>
> > >> Open should fail on unix sockets. Does this fix your problem?
> >
> > AV> WTF? open() _does_ fail on them.
> >
> > Do you think so ? See attachments (sample program, strace and kernel oops).
> > Yes, if open will fail on them it'll be acceptable (not pretty, but
> > acceptable - postgresql will be unable to track socket usage but will
> > start anyway "in hope for best"). Unfortunatelly id DOES NOT fail and then
> > you getting oops (and core dump) out of fcntl.
>
> Ouch... Yes, init_special_inode() should set ->i_fops for sockets. And
> yes, prohibit the open() - if you want to watch the thing you ought to use
> connect(), since anything else will be blatantly non-portable even if we
> make such open() an equivalent of connect().
>
I'm not sure if you can use fcntl with result of connect() but anyway: all
this is not portable and IMO PostgreSQL should use some other technique to
detect dead backend (it uses other ways in fact - it was sort of checks
"just in case"). So, yes, forbidden open() for sockets is Ok. Unlike oops.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:25 EST