Re: 2.4.0-test7 spurious '##' patches

On Fri, Sep 01, 2000 at 03:56:40PM +1100, Keith Owens wrote: On Thu, 31 Aug 2000 21:44:16 -0700, Richard Henderson [EMAIL PROTECTED] wrote: On Thu, Aug 31, 2000 at 07:09:00PM +1100, Keith Owens wrote: Compiling 2.4.0-test7 with the latest IA64 toolchain, gcc version 2.96-ia64-000717 snap

2.2.19 pre13 doesn't like retransmitted SYN ACK packets

2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which arrives after we've sent out the final ACK of the handshake. For example: tcpdump: listening on eth0 15:15:15.075670 wolery.Stanford.EDU.1341 plan9.bell-labs.com.www: S 1057306555:1057306555(0) win 32120 mss

Re: 2.2.19 pre13 doesn't like retransmitted SYN ACK packets

On Thu, Mar 15, 2001 at 05:09:47PM -0300, Henrique de Moraes Holschuh wrote: On Thu, 15 Mar 2001, Zack Weinberg wrote: 2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which arrives after we've sent out the final ACK of the handshake. For example: Ah, that would explain

2.2 PATCH: check return from copy_*_user in fs/pipe.c

The anonymous pipe code in 2.2 does not check the return value of copy_*_user. This can lead to silent loss of data. The appended patch fixes the bug. It has been in continuous use on my machine since May 13 (2.2.19) with no problems. It will apply to any 2.2 kernel from at least 2.2.18,

Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c

On Tue, Jun 19, 2001 at 07:16:23PM -0700, David S. Miller wrote: Zack Weinberg writes: The anonymous pipe code in 2.2 does not check the return value of copy_*_user. This can lead to silent loss of data. I remember Andrew Tridgell (cc:'d) spotting this a long time ago, and we didn't

Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c

Linus Torvalds wrote: If somebody passes in a bad pointer to a system call, you've just invoced the rule of the kernel _may_ be nice to you, but the kernel might just consider you a moron and tell you it worked. There is no lost data or anything else. You've screwed yourself, and you threw

Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c

On Tue, Jun 19, 2001 at 07:52:25PM -0700, David S. Miller wrote: Zack Weinberg writes: It *has* been fixed in 2.4, though. Some sort of compatibility issue? No, some kind of it doesn't matter issue. I can demonstrate user code that behaves differently under 2.2 than 2.4. The example I

Re: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

Kevin Buhr wrote: Jakob Østergaard [EMAIL PROTECTED] writes: Try compiling something like Qt/KDE/gtk-- which are really heavy on templates (with all the benefits and drawbacks of that). Okay, I just compiled gtk-- 1.0.3 (with CFLAGS = "-O2 -g") under three versions of GCC (Debian

[patch 4/4] Distinguish /proc/kmsg access from sys_syslog

Finally, add a new security class for access to /proc/kmsg, distinct from the class used for the read current messages operations on sys_syslog. The dummy and capability modules permit access to /proc/kmsg to any user (who has somehow acquired an open fd on it); SELinux is unchanged. This

[patch 2/4] permission mapping for sys_syslog operations

As suggested by Stephen Smalley: map the various sys_syslog operations to a smaller set of privilege codes before calling security modules. This patch changes the security module interface! There should be no change in the actual security semantics enforced by dummy, capability, nor SELinux (with

[patch 3/4] Refactor do_syslog interface

This patch breaks out the read operations in do_syslog() into their own functions (klog_read, klog_readhist) and adds a klog_poll. klog_read grows the ability to do a nonblocking read, which I expose in the sys_syslog interface because there doesn't seem to be any reason not to. do_syslog itself

[patch 0/4] /proc/kmsg permissions, take four

Here's yet another revision of the /proc/kmsg permissions patch series. To recap, the point is to allow klogd to drop privileges and continue reading from /proc/kmsg (currently, even if klogd has a legitimately opened fd on /proc/kmsg, it cannot read from it unless it has CAP_SYS_ADMIN asserted).

[patch 1/4] Add linux/klog.h

This patch introduces linux/klog.h with symbolic constants for the various sys_syslog() opcodes, and changes all in-kernel references to those opcodes to use the constants. The header is added to the set of user/kernel interface headers. zw Index: linux-2.6/include/linux/Kbuild

[patch 4/4] Distinguish /proc/kmsg access from sys_syslog

Finally, add a new security class for access to /proc/kmsg, distinct from the class used for the read current messages operations on sys_syslog. The dummy and capability modules permit access to /proc/kmsg to any user (who has somehow acquired an open fd on it); SELinux is unchanged. This

[patch 3/4] Refactor do_syslog interface

This patch breaks out the read operations in do_syslog() into their own functions (klog_read, klog_readhist) and adds a klog_poll. klog_read grows the ability to do a nonblocking read, which I expose in the sys_syslog interface because there doesn't seem to be any reason not to. do_syslog itself

[patch 2/4] permission mapping for sys_syslog operations

As suggested by Stephen Smalley: map the various sys_syslog operations to a smaller set of privilege codes before calling security modules. This patch changes the security module interface! There should be no change in the actual security semantics enforced by dummy, capability, nor SELinux (with

[patch 0/4] /proc/kmsg permissions, take three

Here's a re-revised version of my patch set to allow klogd to drop privileges and continue reading from /proc/kmsg (currently, even if klogd has a legitimately opened fd on /proc/kmsg, it cannot read from it unless it has CAP_SYS_ADMIN asserted). SELinux's pickier and finer-grained privilege

[patch 1/4] Add linux/klog.h

This patch introduces linux/klog.h with symbolic constants for the various sys_syslog() opcodes, and changes all in-kernel references to those opcodes to use the constants. The header is added to the set of user/kernel interface headers. (Unlike the previous revision of this patch series, no

Re: [patch 2/4] permission mapping for sys_syslog operations

On 12/14/06, Randy Dunlap [EMAIL PROTECTED] wrote: +#define security_syslog_or_fail(type) do { \ + int error = security_syslog(type); \ + if (error) \ + return error; \ + } while

Re: [patch 1/4] Add linux/klog.h

On 12/14/06, Randy Dunlap [EMAIL PROTECTED] wrote: - (void) do_syslog(0,NULL,0); + (void) do_syslog(KLOG_CLOSE,NULL,0); Please use a space after the commas (even though you just left it as it already was). Will change for the next revision. zw - To unsubscribe from this list: send

Re: [PATCH] uapi/linux/a.out.h: don't use deprecated system-specific predefines.

On 06/02/2017 03:10 AM, Christoph Hellwig wrote: > > Can we please fix these conditionals so that only those > relevant to Linux remain? I was going for the minimal change since this is dusty-deck code that I can't practically test, but I have no objection to your more thorough approach. I don't

[PATCH] uapi/linux/a.out.h: don't use deprecated system-specific predefines.

header that gets this treatment, so IMHO it is worth patching just to drive that number all the way to zero. Signed-off-by: Zack Weinberg <za...@panix.com> --- include/uapi/linux/a.out.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/uapi/linux/a.o

Re: [PATCH] uapi/linux/a.out.h: don't use deprecated system-specific predefines.

On Fri, Jun 2, 2017 at 3:12 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Fri, Jun 2, 2017 at 5:06 AM, Zack Weinberg <za...@panix.com> wrote: >> On 06/02/2017 03:10 AM, Christoph Hellwig wrote: >>> >>> Can we please fix these conditionals s

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

On Thu, Apr 19, 2018 at 10:37 AM, Arnd Bergmann wrote: > Most architectures now use the asm-generic copy of the sysvipc data > structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit > __kernel_time_t on 32-bit architectures but have padding behind them to > allow

Re: Official Linux system wrapper library?

Daniel Colascione wrote: > >> If the kernel provides a system call, libc should provide a C wrapper > >> for it, even if in the opinion of the libc maintainers, that system > >> call is flawed. I would like to state general support for this principle; in fact, I seriously considered preparing

2.2.19 pre13 doesn't like retransmitted SYN ACK packets

2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which arrives after we've sent out the final ACK of the handshake. For example: tcpdump: listening on eth0 15:15:15.075670 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www: S 1057306555:1057306555(0) win 32120

Re: 2.2.19 pre13 doesn't like retransmitted SYN ACK packets

On Thu, Mar 15, 2001 at 05:09:47PM -0300, Henrique de Moraes Holschuh wrote: > On Thu, 15 Mar 2001, Zack Weinberg wrote: > > 2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which > > arrives after we've sent out the final ACK of the handshake. For >

Re: 2.4.0-test7 spurious '##' patches

On Fri, Sep 01, 2000 at 03:56:40PM +1100, Keith Owens wrote: > On Thu, 31 Aug 2000 21:44:16 -0700, > Richard Henderson <[EMAIL PROTECTED]> wrote: > >On Thu, Aug 31, 2000 at 07:09:00PM +1100, Keith Owens wrote: > >> Compiling 2.4.0-test7 with the latest IA64 toolchain, gcc version > >>

2.2 PATCH: check return from copy_*_user in fs/pipe.c

The anonymous pipe code in 2.2 does not check the return value of copy_*_user. This can lead to silent loss of data. The appended patch fixes the bug. It has been in continuous use on my machine since May 13 (2.2.19) with no problems. It will apply to any 2.2 kernel from at least 2.2.18,

Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c

On Tue, Jun 19, 2001 at 07:16:23PM -0700, David S. Miller wrote: > > Zack Weinberg writes: > > The anonymous pipe code in 2.2 does not check the return value of > > copy_*_user. This can lead to silent loss of data. > > I remember Andrew Tridgell (cc:'d) spottin

Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c

Linus Torvalds wrote: > If somebody passes in a bad pointer to a system call, you've just > invoced the rule of "the kernel _may_ be nice to you, but the kernel > might just consider you a moron and tell you it worked". > > There is no "lost data" or anything else. You've screwed yourself, and >

Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c

On Tue, Jun 19, 2001 at 07:52:25PM -0700, David S. Miller wrote: > > Zack Weinberg writes: > > It *has* been fixed in 2.4, though. Some sort of compatibility issue? > > No, some kind of "it doesn't matter" issue. I can demonstrate user code that behaves di

Re: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

Kevin Buhr wrote: > Jakob Østergaard <[EMAIL PROTECTED]> writes: > > > > Try compiling something like Qt/KDE/gtk-- which are really heavy on > > templates (with all the benefits and drawbacks of that). > > Okay, I just compiled gtk-- 1.0.3 (with CFLAGS = "-O2 -g") under three > versions of GCC

[patch 4/4] Distinguish /proc/kmsg access from sys_syslog

Finally, add a new security class for access to /proc/kmsg, distinct from the class used for the "read current messages" operations on sys_syslog. The dummy and capability modules permit access to /proc/kmsg to any user (who has somehow acquired an open fd on it); SELinux is unchanged. This

[patch 2/4] permission mapping for sys_syslog operations

As suggested by Stephen Smalley: map the various sys_syslog operations to a smaller set of privilege codes before calling security modules. This patch changes the security module interface! There should be no change in the actual security semantics enforced by dummy, capability, nor SELinux (with

[patch 3/4] Refactor do_syslog interface

This patch breaks out the read operations in do_syslog() into their own functions (klog_read, klog_readhist) and adds a klog_poll. klog_read grows the ability to do a nonblocking read, which I expose in the sys_syslog interface because there doesn't seem to be any reason not to. do_syslog itself

[patch 0/4] /proc/kmsg permissions, take four

Here's yet another revision of the /proc/kmsg permissions patch series. To recap, the point is to allow klogd to drop privileges and continue reading from /proc/kmsg (currently, even if klogd has a legitimately opened fd on /proc/kmsg, it cannot read from it unless it has CAP_SYS_ADMIN asserted).

[patch 1/4] Add

This patch introduces with symbolic constants for the various sys_syslog() opcodes, and changes all in-kernel references to those opcodes to use the constants. The header is added to the set of user/kernel interface headers. zw Index: linux-2.6/include/linux/Kbuild

[patch 4/4] Distinguish /proc/kmsg access from sys_syslog

Finally, add a new security class for access to /proc/kmsg, distinct from the class used for the "read current messages" operations on sys_syslog. The dummy and capability modules permit access to /proc/kmsg to any user (who has somehow acquired an open fd on it); SELinux is unchanged. This

[patch 3/4] Refactor do_syslog interface

This patch breaks out the read operations in do_syslog() into their own functions (klog_read, klog_readhist) and adds a klog_poll. klog_read grows the ability to do a nonblocking read, which I expose in the sys_syslog interface because there doesn't seem to be any reason not to. do_syslog itself

[patch 2/4] permission mapping for sys_syslog operations

As suggested by Stephen Smalley: map the various sys_syslog operations to a smaller set of privilege codes before calling security modules. This patch changes the security module interface! There should be no change in the actual security semantics enforced by dummy, capability, nor SELinux (with

[patch 0/4] /proc/kmsg permissions, take three

Here's a re-revised version of my patch set to allow klogd to drop privileges and continue reading from /proc/kmsg (currently, even if klogd has a legitimately opened fd on /proc/kmsg, it cannot read from it unless it has CAP_SYS_ADMIN asserted). SELinux's pickier and finer-grained privilege

[patch 1/4] Add

This patch introduces with symbolic constants for the various sys_syslog() opcodes, and changes all in-kernel references to those opcodes to use the constants. The header is added to the set of user/kernel interface headers. (Unlike the previous revision of this patch series, no kernel-private

Re: [patch 2/4] permission mapping for sys_syslog operations

On 12/14/06, Randy Dunlap <[EMAIL PROTECTED]> wrote: > +#define security_syslog_or_fail(type) do { \ > + int error = security_syslog(type); \ > + if (error) \ > + return error; \ > + }

Re: [patch 1/4] Add

On 12/14/06, Randy Dunlap <[EMAIL PROTECTED]> wrote: > - (void) do_syslog(0,NULL,0); > + (void) do_syslog(KLOG_CLOSE,NULL,0); Please use a space after the commas (even though you just left it as it already was). Will change for the next revision. zw - To unsubscribe from this list:

Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

On Thu, Apr 19, 2018 at 10:37 AM, Arnd Bergmann wrote: > Most architectures now use the asm-generic copy of the sysvipc data > structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit > __kernel_time_t on 32-bit architectures but have padding behind them to > allow extending the type to

[PATCH] uapi/linux/a.out.h: don't use deprecated system-specific predefines.

header that gets this treatment, so IMHO it is worth patching just to drive that number all the way to zero. Signed-off-by: Zack Weinberg --- include/uapi/linux/a.out.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/uapi/linux/a.out.h b/include/uapi/linux

Re: [PATCH] uapi/linux/a.out.h: don't use deprecated system-specific predefines.

On 06/02/2017 03:10 AM, Christoph Hellwig wrote: > > Can we please fix these conditionals so that only those > relevant to Linux remain? I was going for the minimal change since this is dusty-deck code that I can't practically test, but I have no objection to your more thorough approach. I don't

Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces

On Fri, Oct 30, 2020 at 9:57 AM Cyril Hrubis wrote: > > According to patch description [1] and time_namespaces documentation > > [2] the CLOCK_REALTIME is not supported (for now?) to avoid complexity > > and overhead in the kernel. ... > > To be more specific - [if this were supported] it would

Re: Official Linux system wrapper library?

Daniel Colascione wrote: > >> If the kernel provides a system call, libc should provide a C wrapper > >> for it, even if in the opinion of the libc maintainers, that system > >> call is flawed. I would like to state general support for this principle; in fact, I seriously considered preparing

Re: rseq/x86: choosing rseq code signature

On Tue, Apr 9, 2019 at 4:43 PM Mathieu Desnoyers wrote: > - On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers > mathieu.desnoy...@efficios.com wrote: > > > > We are about to include the code signature required prior to restartable > > sequences abort handlers into glibc, which will make this ABI

Re: [Y2038] Question regarding support of old time interfaces beyond y2038

On Tue, Mar 5, 2019 at 10:24 AM Lukasz Majewski wrote: > From other discussion [4] - regarding the following system calls: > time, stime, gettimeofday, settimeofday, adjtimex, nanosleep, alarm, > getitimer, setitimer, select, utime, utimes, futimesat, and > {old,new}{l,f,}stat{,64}. > > "These

Re: [PATCH] uapi/linux/a.out.h: don't use deprecated system-specific predefines.

On Fri, Jun 2, 2017 at 3:12 PM, Linus Torvalds wrote: > On Fri, Jun 2, 2017 at 5:06 AM, Zack Weinberg wrote: >> On 06/02/2017 03:10 AM, Christoph Hellwig wrote: >>> >>> Can we please fix these conditionals so that only those >>> relevant to Linux remain? >