Bug 19535

Summary: procfs_rlimit tidyup
Product: Base System Reporter: Adrian Chadd <adrian>
Component: kernAssignee: Mateusz Guzik <mjg>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: gonzo, mjg
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description Adrian Chadd freebsd_committer freebsd_triage 2000-06-26 22:20:01 UTC 
A quick tidyup of procfs_rlimit.c. Specifically, making the code a little
more style(9) compliant, and taking out a char[512] which is bad juju
in kernel code.

Fix: Apply this patch:
How-To-Repeat: 
N/A
Comment 1 Garrett A. Wollman 2000-06-27 16:29:22 UTC 
<<On Mon, 26 Jun 2000 23:12:45 +0200 (CEST), adrian@FreeBSD.ORG said:

> +	psbuf = (char *)malloc(512 * sizeof(char), M_TEMP, M_WAITOK);

sizeof(char) is defined to be 1.

> +		/* XXX conservative, but potentially overflowable */

It should be possible to compute the exact buffer size.  Since this
code is not frequently run, I would suggest that a two-pass approach
would not hurt.


-GAWollman
Comment 2 Adrian Chadd freebsd_committer freebsd_triage 2000-06-27 16:49:22 UTC 
On Tue, Jun 27, 2000, Garrett Wollman wrote:
> <<On Mon, 26 Jun 2000 23:12:45 +0200 (CEST), adrian@FreeBSD.ORG said:
> 
> > +	psbuf = (char *)malloc(512 * sizeof(char), M_TEMP, M_WAITOK);
> 
> sizeof(char) is defined to be 1.

Being pedantic.

> > +		/* XXX conservative, but potentially overflowable */
> 
> It should be possible to compute the exact buffer size.  Since this
> code is not frequently run, I would suggest that a two-pass approach
> would not hurt.

I'm going to go through later on and redo this repeated evilness in
procfs. I thought I'd submit this change now to get rid of the
blantant hacks.



Adrian

-- 
Adrian Chadd			Build a man a fire, and he's warm for the
<adrian@FreeBSD.org>		rest of the evening. Set a man on fire and
				he's warm for the rest of his life.
Comment 3 Adrian Chadd freebsd_committer freebsd_triage 2000-07-04 08:29:45 UTC 
Responsible Changed
From-To: freebsd-bugs->adrian

I can commit my own PRs now.
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2004-09-13 06:46:43 UTC 
Responsible Changed
From-To: adrian->freebsd-bugs

With bugmeister hat on, reassign from recently inactive committer.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2005-10-24 03:16:03 UTC 
State Changed
From-To: open->suspended

Mark as 'suspended' since this does not seem as though it is being 
actively worked on.
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:53:36 UTC 
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"
Comment 7 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-22 22:37:42 UTC 
Adrian, do you have any plans committing this or can the PR be closed?
Comment 8 Adrian Chadd freebsd_committer freebsd_triage 2019-01-23 00:04:10 UTC 
holy crap i wonder if this is still a problem!
Comment 9 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:38:48 UTC 
Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
Comment 10 Mateusz Guzik freebsd_committer freebsd_triage 2023-08-22 17:01:20 UTC 
the code was switched to sbuf years ago

that lim_hold is very susipicious vs process exit, but that's another story