"J. Bruce Fields" writes:
> On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote:
>> Tatsukawa Kosuke wrote:
>> > J. Bruce Fields wrote:
>> >> Thanks for the detailed investigation.
>> >>
>> >> I think it would be worth adding a comment if that might help someone
>> >> having to rein
Kosuke Tatsukawa writes:
> There are several places in net/sunrpc/svcsock.c which calls
> waitqueue_active() without calling a memory barrier. Add a memory
> barrier just as in wq_has_sleeper().
>
> I found this issue when I was looking through the linux source code
> for places calling waitqueu
On Saturday February 23, [EMAIL PROTECTED] wrote:
> On Wed, 20 Feb 2008 15:46:10 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > Another posting of the full swap over NFS series.
>
> Well I looked. There's rather a lot of it and I wouldn't pretend to
> understand it.
But pretending is fu
On Thursday January 10, [EMAIL PROTECTED] wrote:
> On Thu, Jan 10, 2008 at 03:13:48PM +1100, Neil Brown wrote:
> > > What guarantees that it doesn't happen before we get to callback? AFAICS,
> > > nothing whatsoever...
> >
> > Yes, that's bad isn&
On Tuesday January 8, [EMAIL PROTECTED] wrote:
>
> FWIW, I'm going to go through Arjan's collection and post blow-by-blow
> analysis of some of those suckers. Tonight, probably...
>
> Let's take e.g. http://www.kerneloops.org/raw.php?rawid=2618
Thanks for that analysis.
...
>
> Humm... So we
On Tuesday November 13, [EMAIL PROTECTED] wrote:
> On Tuesday 13 November 2007 07:08, Mark Lord wrote:
> > Ingo Molnar wrote:
> > ..
> >
> > > This is all QA-101 that _cannot be argued against on a rational basis_,
> > > it's just that these sorts of things have been largely ignored for
> > > years
On Wednesday November 14, [EMAIL PROTECTED] wrote:
> On Wed, Nov 14, 2007 at 09:38:20AM -0800, Randy Dunlap wrote:
> > On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote:
> > > so please stop this "too busy and too noisy" nonsense already. It was
> > > nonsense 10 years ago and it's nonsense tod
On Monday October 22, [EMAIL PROTECTED] wrote:
> Here is a second missing part of the IPv6 support in NFS server code
> concerning knfd syscall interface.
> It updates write_getfd and write_getfd to accept IPv6 addresses.
Sorry for not replying to this earlier - I saw the Oct 12 post and
thought
it aaf68cfbf2241d24d46583423f6bff5c47e088b3 added a bias
to sk_inuse, so this test for an unused socket now fails. So no
sockets gets closed because they are old (they might get closed
if the client closed them).
This bug has existed since 2.6.21-rc1.
Thanks to Wolfgang Walter for finding and repo
On Tuesday September 11, [EMAIL PROTECTED] wrote:
> This oops appeared over night on a box running 2.6.23-rc5 (recent with the
> tcp_input.c fix).
>
> I can't find a similar one reported.
Okay. this is weird.
>
> Mark
>
>
> BUG: unable to handle kernel NULL pointer dereference at virtual
On Wednesday September 5, [EMAIL PROTECTED] wrote:
> On Wednesday August 22, [EMAIL PROTECTED] wrote:
> > Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253290
> > >
> > > 18:57:54 osama kernel: [] kernel_recvmsg+0x31/0x40
> > > 18:57:54 osama k
On Wednesday August 22, [EMAIL PROTECTED] wrote:
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253290
> >
> > 18:57:54 osama kernel: [] kernel_recvmsg+0x31/0x40
> > 18:57:54 osama kernel: [] svc_udp_recvfrom+0x114/0x368 [sunrpc]
>
> svc_udp_r
On Thursday August 9, [EMAIL PROTECTED] wrote:
> Here is a small part of missing pieces of IPv6 support for the server.
> It deals with the ip_map caching code part.
>
> It changes the ip_map structure to be able to store INET6 addresses.
> It adds also the changes in address hashing, and mapping
On Thursday August 9, [EMAIL PROTECTED] wrote:
> >>
> >> How have you tested the effectiveness of the new hash function?
> >
> > I have not tested that point but I can easily imagine there are better
> > solutions.
> > Perhaps we can keep the same function for an IPv4 address (only taking
> > th
On Monday March 5, [EMAIL PROTECTED] wrote:
> On Friday 02 March 2007 05:28, NeilBrown wrote:
> > The sunrpc server code needs to know the source and destination address
> > for UDP packets so it can reply properly.
> > It currently copies code out of the network stack to pick the pieces out
> > of
On Monday March 5, [EMAIL PROTECTED] wrote:
>
> Hi Neil,
>
> here's another minor comment:
>
> On Friday 02 March 2007 05:28, NeilBrown wrote:
> > +static inline void svc_udp_get_dest_address(struct svc_rqst *rqstp,
> > + struct cmsghdr *cmh)
> > {
> >
On Monday February 12, [EMAIL PROTECTED] wrote:
> Quoting YOSHIFUJIHideaki/=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=
> > In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 18:12:16 -0800),
> Andrew Morton <[EMAIL PROTECTED]> says:
> >
> > > > On Mon, 12 Feb 2007 20:10:13 -0500 (EST) Pete Clem
On Friday February 9, [EMAIL PROTECTED] wrote:
>
> Ok. Now... any questions?
>
Yes. Does this require a closed user-space helper like the other
3945ABG driver, or is it completely open (maybe excepting firmware)?
Thanks,
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe ne
I upgraded my notebook from 2.6.16 to 2.6.18 recently and noticed that
I couldn't talk to my VOIP device (which has a WEB interface).
Watching traffic I see the three-way-handshake working perfectly, and
then the first data packet is sent (a partial HTTP request:
GET / HTTP/1.1 ) and an ACK c
On Thursday August 17, [EMAIL PROTECTED] wrote:
> Andrew Morton wrote:
> > Daniel Phillips <[EMAIL PROTECTED]> wrote:
> >>What happened to the case where we just fill memory full of dirty file
> >>pages backed by a remote disk?
> >
> > Processes which are dirtying those pages throttle at
> > /proc
On Monday August 14, [EMAIL PROTECTED] wrote:
> On Sun, 2006-08-13 at 22:22 -0700, Andrew Morton wrote:
> >
> > We could track dirty anonymous memory and throttle.
> >
> > Also, there must be some value of /proc/sys/vm/min_free_kbytes at which a
> > machine is no longer deadlockable with any of t
On Wednesday November 23, [EMAIL PROTECTED] wrote:
> On Wed, Nov 23, 2005 at 04:31:14AM -0800, Lever, Charles wrote:
> > so i don't remember why you are removing xdr_decode_string. are we sure
> > that no-one will need this functionality in the future? it is harmless
> > to remove today, but i wo
22 matches
Mail list logo
