Hi Christopher,
On Wed, 2014-06-11 at 09:22 -0700, Christoph Hellwig wrote:
> On Wed, Jun 11, 2014 at 09:15:18AM -0700, Philippe Troin wrote:
> > So, the only regression remaining between 3.13.11 and 3.14.6 + your
> > patch is the one where listxattr(2) and friends do no
Hi Christopher,
On Wed, 2014-06-11 at 09:22 -0700, Christoph Hellwig wrote:
On Wed, Jun 11, 2014 at 09:15:18AM -0700, Philippe Troin wrote:
So, the only regression remaining between 3.13.11 and 3.14.6 + your
patch is the one where listxattr(2) and friends do not NUL-terminate the
xattr
Christoph,
On Wed, 2014-06-11 at 00:24 -0700, Christoph Hellwig wrote:
> On Tue, Jun 10, 2014 at 02:20:03PM -0700, Philippe Troin wrote:
> > Trond, Christoph,
> >
> > Since my last email, I've been testing 3.14.6.
> > Stock 3.14.6 is still broken, and Christoph'
Christoph,
On Wed, 2014-06-11 at 00:24 -0700, Christoph Hellwig wrote:
On Tue, Jun 10, 2014 at 02:20:03PM -0700, Philippe Troin wrote:
Trond, Christoph,
Since my last email, I've been testing 3.14.6.
Stock 3.14.6 is still broken, and Christoph's patch does help, but does
not entirely
Trond, Christoph,
Since my last email, I've been testing 3.14.6.
Stock 3.14.6 is still broken, and Christoph's patch does help, but does
not entirely cure the problem.
On Sat, 2014-06-07 at 19:48 -0700, Philippe Troin wrote:
> It's still broken, but in a different way.
> The phantom
Trond, Christoph,
Since my last email, I've been testing 3.14.6.
Stock 3.14.6 is still broken, and Christoph's patch does help, but does
not entirely cure the problem.
On Sat, 2014-06-07 at 19:48 -0700, Philippe Troin wrote:
It's still broken, but in a different way.
The phantom attrs are gone
On Mon, 2014-06-09 at 10:46 -0400, J. Bruce Fields wrote:
> On Sat, Jun 07, 2014 at 07:48:21PM -0700, Philippe Troin wrote:
> > Hi Trond & Christoph,
> >
> > It's still broken, but in a different way.
> > The phantom attrs are gone, but the attr/acl interaction is
On Mon, 2014-06-09 at 10:46 -0400, J. Bruce Fields wrote:
On Sat, Jun 07, 2014 at 07:48:21PM -0700, Philippe Troin wrote:
Hi Trond Christoph,
It's still broken, but in a different way.
The phantom attrs are gone, but the attr/acl interaction is still
uncertain.
I have tested
Hi Trond & Christoph,
It's still broken, but in a different way.
The phantom attrs are gone, but the attr/acl interaction is still
uncertain.
I have tested vanilla 3.14.5 + this patch on x86_64.
Mount options are the same as last time (NFSv3).
This is what I see on the client:
Hi Trond Christoph,
It's still broken, but in a different way.
The phantom attrs are gone, but the attr/acl interaction is still
uncertain.
I have tested vanilla 3.14.5 + this patch on x86_64.
Mount options are the same as last time (NFSv3).
This is what I see on the client:
This happens on an NFS client running on:
Linux ceramic32 3.14.4 #1 SMP Fri May 30 00:52:07 PDT 2014 i686 i686 i386
GNU/Linux
(also happens on x86_64).
The NFS server can be either 3.14 or 3.13, it doesn't change a thing.
Mount options are:
(from /proc/mtab)
ceramic:/export/home/phil /home/phil
This happens on an NFS client running on:
Linux ceramic32 3.14.4 #1 SMP Fri May 30 00:52:07 PDT 2014 i686 i686 i386
GNU/Linux
(also happens on x86_64).
The NFS server can be either 3.14 or 3.13, it doesn't change a thing.
Mount options are:
(from /proc/mtab)
ceramic:/export/home/phil /home/phil
On Tue, 2012-10-16 at 10:13 +1100, Dave Chinner wrote:
> On Mon, Oct 15, 2012 at 11:36:15PM +0200, Juliusz Chroboczek wrote:
> > Hi,
> >
> > The Linux manual page for write(2) says:
> >
> > The adjustment of the file offset and the write operation are
> > performed as an atomic step.
>
On Tue, 2012-10-16 at 10:13 +1100, Dave Chinner wrote:
On Mon, Oct 15, 2012 at 11:36:15PM +0200, Juliusz Chroboczek wrote:
Hi,
The Linux manual page for write(2) says:
The adjustment of the file offset and the write operation are
performed as an atomic step.
That's wrong.
System info:
Linux 2.6.20-1.2320.fc5 SMP x86_64
lspci:
00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07)
00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05)
00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03)
00:07.2 SMBus: Advanced
System info:
Linux 2.6.20-1.2320.fc5 SMP x86_64
lspci:
00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07)
00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05)
00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03)
00:07.2 SMBus: Advanced
Wakko Warner <[EMAIL PROTECTED]> writes:
> [84797.683873] sr 1:0:13:0: scsi: Device offlined - not ready after error
> recovery
>
> Is there anyway to make the kernel "online" a device that has done this?
> I've had this happen on various devices (mostly on usb where I can
> unplug/replug),
Wakko Warner [EMAIL PROTECTED] writes:
[84797.683873] sr 1:0:13:0: scsi: Device offlined - not ready after error
recovery
Is there anyway to make the kernel online a device that has done this?
I've had this happen on various devices (mostly on usb where I can
unplug/replug), but this
Roland Kuhn <[EMAIL PROTECTED]> writes:
> Hi Guillaume!
>
> On 2 Feb 2007, at 14:48, Guillaume Chazarain wrote:
>
> > 2007/2/2, Roland Kuhn <[EMAIL PROTECTED]>:
> >
> >> That's a bug, right?
> >
> > No, if you want something like: (echo toto; date; echo titi) > file
> > to work in your shell,
Roland Kuhn [EMAIL PROTECTED] writes:
Hi Guillaume!
On 2 Feb 2007, at 14:48, Guillaume Chazarain wrote:
2007/2/2, Roland Kuhn [EMAIL PROTECTED]:
That's a bug, right?
No, if you want something like: (echo toto; date; echo titi) file
to work in your shell, you'll be happy to have
Denis Vlasenko <[EMAIL PROTECTED]> writes:
> What share the same file descriptor? MC and programs started from it?
All the processes started from your shell share at least fds 0, 1 and 2.
> I thought after exec() fds atre either closed (if CLOEXEC) or
> becoming independent from parent process
Denis Vlasenko [EMAIL PROTECTED] writes:
What share the same file descriptor? MC and programs started from it?
All the processes started from your shell share at least fds 0, 1 and 2.
I thought after exec() fds atre either closed (if CLOEXEC) or
becoming independent from parent process
"Yakov Lerner" <[EMAIL PROTECTED]> writes:
> Does /proc have any entries to flip the "software read-only flag"
> for a partition or disk (which are physically read-write) ?
No, but you can use blockdev --setro /dev/hdXX
Phil.
-
To unsubscribe from this list: send the line "unsubscribe
Denis Vlasenko <[EMAIL PROTECTED]> writes:
> Hi,
>
> I am currently on Linux 2.6.18, x86_64.
> I came across strange behavior while working on one
> of busybox applets. I narrowed it down to these two
> trivial testcases:
>
> #include
> #include
> int main() {
> fcntl(0, F_SETFL,
Denis Vlasenko [EMAIL PROTECTED] writes:
Hi,
I am currently on Linux 2.6.18, x86_64.
I came across strange behavior while working on one
of busybox applets. I narrowed it down to these two
trivial testcases:
#include unistd.h
#include fcntl.h
int main() {
fcntl(0, F_SETFL,
Yakov Lerner [EMAIL PROTECTED] writes:
Does /proc have any entries to flip the software read-only flag
for a partition or disk (which are physically read-write) ?
No, but you can use blockdev --setro /dev/hdXX
Phil.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Lee Revell <[EMAIL PROTECTED]> writes:
> On Mon, 2005-07-25 at 13:55 -0400, Steven Rostedt wrote:
> > Doesn't matter. The cycles saved for old compilers is not rational to
> > have obfuscated code.
>
> Where do we draw the line with this? Is x *= 2 preferable to x <<= 2 as
> well?
Depends if
Lee Revell [EMAIL PROTECTED] writes:
On Mon, 2005-07-25 at 13:55 -0400, Steven Rostedt wrote:
Doesn't matter. The cycles saved for old compilers is not rational to
have obfuscated code.
Where do we draw the line with this? Is x *= 2 preferable to x = 2 as
well?
Depends if you want to
"Theodore Ts'o" <[EMAIL PROTECTED]> writes:
> On Mon, Jul 11, 2005 at 12:32:37PM +0200, Paolo Ornati wrote:
> > But what I'm looking for is a list of syscalls that are automatically
> > restarted when SA_RESTART is set, and especially in what conditions.
> >
> > For example: read(), write(),
Theodore Ts'o [EMAIL PROTECTED] writes:
On Mon, Jul 11, 2005 at 12:32:37PM +0200, Paolo Ornati wrote:
But what I'm looking for is a list of syscalls that are automatically
restarted when SA_RESTART is set, and especially in what conditions.
For example: read(), write(), open() are
Sheo Shanker Prasad <[EMAIL PROTECTED]> writes:
> I will appreciate your help in eliminating a disturbing wide
> variation (by a factors of 2 to 2.5) in the execution time of a test
> (execution benchmark) program under identical conditions even when
> the machine is freshly started (rebooted)
Sheo Shanker Prasad [EMAIL PROTECTED] writes:
I will appreciate your help in eliminating a disturbing wide
variation (by a factors of 2 to 2.5) in the execution time of a test
(execution benchmark) program under identical conditions even when
the machine is freshly started (rebooted) and no
Willy Tarreau <[EMAIL PROTECTED]> writes:
> On Wed, Mar 02, 2005 at 02:00:30PM -0800, Philippe Troin wrote:
>
> > + /* Asus K8V Se Deluxe bugfix. Correct VPD content */
> > + /* MBo April 2004 */
> > + if( ((unsigned char)pAC->vpd.vpd_buf[0x3f] == 0x38) &
Willy Tarreau [EMAIL PROTECTED] writes:
On Wed, Mar 02, 2005 at 02:00:30PM -0800, Philippe Troin wrote:
+ /* Asus K8V Se Deluxe bugfix. Correct VPD content */
+ /* MBo April 2004 */
+ if( ((unsigned char)pAC-vpd.vpd_buf[0x3f] == 0x38)
+ ((unsigned char)pAC-vpd.vpd_buf
It contains a patch for 2.6 that fixs the problem. Enclosed is a copy
of this patch for 2.4.29. Please consider applying.
Phil.
Signed-Off-By: Philippe Troin <[EMAIL PROTECTED]>
diff -ruN linux-2.4.29.orig/drivers/net/sk98lin/skvpd.c
linux-2.4.29/drivers/net/sk98lin/skvpd.c
--- linux-2.4.29.orig/d
Running
Linux 2.4.29 #1 SMP Mon Feb 21 02:11:56 PST 2005 i686 unknown
on an Asus K8W SE Deluxe, bios 1005 with an embedded via82cxxx audio
controller:
00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio
Controller (rev 60)
Subsystem: Asustek Computer, Inc.:
Running
Linux 2.4.29 #1 SMP Mon Feb 21 02:11:56 PST 2005 i686 unknown
on an Asus K8W SE Deluxe, bios 1005 with an embedded via82cxxx audio
controller:
00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio
Controller (rev 60)
Subsystem: Asustek Computer, Inc.:
It contains a patch for 2.6 that fixs the problem. Enclosed is a copy
of this patch for 2.4.29. Please consider applying.
Phil.
Signed-Off-By: Philippe Troin [EMAIL PROTECTED]
diff -ruN linux-2.4.29.orig/drivers/net/sk98lin/skvpd.c
linux-2.4.29/drivers/net/sk98lin/skvpd.c
--- linux-2.4.29.orig/drivers
Philippe Troin <[EMAIL PROTECTED]> writes:
[Please CC me on the replies]
This is seen on a dual-242 set-up with 2 GB of RAM running a i386
kernel (not x86_64).
2.4.27 and 2.4.28 also showed the problem.
Enclosed is the dmesg log and the lspci -vvv output.
Configuration available upon r
Philippe Troin [EMAIL PROTECTED] writes:
[Please CC me on the replies]
This is seen on a dual-242 set-up with 2 GB of RAM running a i386
kernel (not x86_64).
2.4.27 and 2.4.28 also showed the problem.
Enclosed is the dmesg log and the lspci -vvv output.
Configuration available upon request
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> On 12 Apr 2001, Philippe Troin wrote:
>
> > Apt I guess ? It has a very strange behavior when backgrounded...
>
> Not really, just want it tries to run dpkg it hangs.
>
> > > The last read was after the pro
Jason Gunthorpe [EMAIL PROTECTED] writes:
On 12 Apr 2001, Philippe Troin wrote:
Apt I guess ? It has a very strange behavior when backgrounded...
Not really, just want it tries to run dpkg it hangs.
The last read was after the process was forgrounded. The read waits
forever
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> I've run into the following weird behavior on my system with 2.4.0. I have
> the following code:
Apt I guess ? It has a very strange behavior when backgrounded...
> if (fork() == 0)
> {
> int Flags,dummy;
> if ((Flags =
Jason Gunthorpe [EMAIL PROTECTED] writes:
I've run into the following weird behavior on my system with 2.4.0. I have
the following code:
Apt I guess ? It has a very strange behavior when backgrounded...
if (fork() == 0)
{
int Flags,dummy;
if ((Flags =
Got this oops (captured by kmsgdump) today.
The machine was completely stuck.
Phil.
ksymoops 2.3.4 on i686 2.2.17. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.17/ (default)
-m /boot/System.map-2.2.17
Got this oops (captured by kmsgdump) today.
The machine was completely stuck.
Phil.
ksymoops 2.3.4 on i686 2.2.17. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.17/ (default)
-m /boot/System.map-2.2.17
"David S. Miller" <[EMAIL PROTECTED]> writes:
>From: Philippe Troin <[EMAIL PROTECTED]>
>Date: 03 Nov 2000 19:53:04 -0800
>
>Yes I agree, mixing signed and unsigned arithmetic is evil... Doesn't
>gcc have a flag for unsafe signed/unsigned
"David S. Miller" [EMAIL PROTECTED] writes:
From: Philippe Troin [EMAIL PROTECTED]
Date: 03 Nov 2000 19:53:04 -0800
Yes I agree, mixing signed and unsigned arithmetic is evil... Doesn't
gcc have a flag for unsafe signed/unsigned mixtures ?
Would you consider
I found this in all 2.2.x kernels, and it might possibly be present in
2.4.x too...
When receiving file descriptors via recvmsg(), scm_detach_fds() in
net/core/scm.c can overflow user space data at msg_control if
msg_controllen is less than sizeof(struct cmsghdr).
This is a security problem.
Rob Landley <[EMAIL PROTECTED]> writes:
> --- Philippe Troin <[EMAIL PROTECTED]> wrote:
> > All the code I've encountered which actually needed
> > to perform
> > broadcast on all interfaces was sending
> > subnet-directed broadcasts by
> > hand on all
Rob Landley [EMAIL PROTECTED] writes:
--- Philippe Troin [EMAIL PROTECTED] wrote:
All the code I've encountered which actually needed
to perform
broadcast on all interfaces was sending
subnet-directed broadcasts by
hand on all interfaces.
Bind to a socket to a local port and query
I found this in all 2.2.x kernels, and it might possibly be present in
2.4.x too...
When receiving file descriptors via recvmsg(), scm_detach_fds() in
net/core/scm.c can overflow user space data at msg_control if
msg_controllen is less than sizeof(struct cmsghdr).
This is a security problem.
Rob Landley <[EMAIL PROTECTED]> writes:
> --- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > Rob Landley wrote:
> > > Under 2.2.16, broadcast packets addressed to
> > > 255.255.255.255 do not go out to all interfaces in
> > a
> > > machine with multiple network cards. They're
> > getting
> > >
Rob Landley [EMAIL PROTECTED] writes:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Rob Landley wrote:
Under 2.2.16, broadcast packets addressed to
255.255.255.255 do not go out to all interfaces in
a
machine with multiple network cards. They're
getting
routed out the default
Matti Aarnio <[EMAIL PROTECTED]> writes:
> We ([EMAIL PROTECTED] -> me & DaveM) got just reports that
> somebody is diverting incoming email to some sort of auto-responding
> ticket system.
>
> The thing does not carry original message "Received:" headers in replies,
> and is reporting invalid
Matti Aarnio [EMAIL PROTECTED] writes:
We ([EMAIL PROTECTED] - me DaveM) got just reports that
somebody is diverting incoming email to some sort of auto-responding
ticket system.
The thing does not carry original message "Received:" headers in replies,
and is reporting invalid URL.
I've seen that in the past, but never had time to investigate. For
some reasons, TCP sessions get stuck.
Here'an example with a ssh session:
1) Netstat says on tantale (note the non-zero Send-Q):
tcp 0 38364 tantale:ssh neptune:1022 ESTABLISHED
Netstat says on neptune:
I've seen that in the past, but never had time to investigate. For
some reasons, TCP sessions get stuck.
Here'an example with a ssh session:
1) Netstat says on tantale (note the non-zero Send-Q):
tcp 0 38364 tantale:ssh neptune:1022 ESTABLISHED
Netstat says on neptune:
kjh63 <[EMAIL PROTECTED]> writes:
> > How Linux Kernel and BPF relate to each other:
> >
> > a) linux has BPF (I don't think so).
It has LSF, the Linux Socket Filter.
> > b) Linux has own equivalent of BPF (part of NAT?)
Yes, the LSF.
> > c) linux does not have anything like BPF
BPF opcodes
kjh63 [EMAIL PROTECTED] writes:
How Linux Kernel and BPF relate to each other:
a) linux has BPF (I don't think so).
It has LSF, the Linux Socket Filter.
b) Linux has own equivalent of BPF (part of NAT?)
Yes, the LSF.
c) linux does not have anything like BPF
BPF opcodes works on
60 matches
Mail list logo
