On 2013-03-28, Andriy Gapon wrote:
Would like to ask for opinions on this topic...
Please read this PR for context:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838
So I would like to commit the following patch sooner rather than later:
I have revised the patch slightly:
On 2013-06-13, Hans Petter Selasky wrote:
Can we introduce a new syntax while keeping the old behaviour?
path zvol/* hide-r
path zvol/* unhide-r
I think this will be more accepted than changing existing behaviour!
IMHO, the old behavior is so confusing and unintuitive that we should
not
On 2012-12-10, Greg 'groggy' Lehey wrote:
Unfortunately r205821 [1] has caused several regressions to calendar(1).
Relevant PRs:
bin/157718
bin/162211
bin/168785
bin/170930
Some regressions were fixed in summer 2011 but they are still lacking
MFCs.
Is anyone aware of
On 2013-03-28, Andriy Gapon wrote:
Would like to ask for opinions on this topic...
Please read this PR for context:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838
Especially Jaakko's insightful description of the problem.
So I would like to commit the following patch sooner
Hi!
On 2012-12-10, Greg 'groggy' Lehey wrote:
Unfortunately r205821 [1] has caused several regressions to calendar(1).
Relevant PRs:
bin/157718
bin/162211
bin/168785
bin/170930
I think we fix bugs rather than revert the commits.
Of course it's preferred but I didn't see any
On 2012-12-07, Devin Teske wrote:
Can you re-test with the attached patch?
Works for me. Thanks!
http://people.freebsd.org/~jh/misc/menu-patched.png
--
Jaakko
___
freebsd-hackers@freebsd.org mailing list
Hi,
Unfortunately r205821 [1] has caused several regressions to calendar(1).
Relevant PRs:
bin/157718
bin/162211
bin/168785
bin/170930
Some regressions were fixed in summer 2011 but they are still lacking
MFCs.
Is anyone aware of possible problems that reverting calendar(1) to
pre-r205821
Hi,
I plan to commit the patch below to disallow attaching preloaded memory
disks via ioctl. I didn't find anything that would really use this
undocumented feature.
---
Disallow attaching preloaded memory disks via ioctl.
- The feature is dangerous because the kernel code doesn't check
On 2011-07-05, Julian H. Stacey wrote:
Jaakko Heinonen wrote:
On 2011-07-05, Julian H. Stacey wrote:
There's a regression error with calendar between FreeBSD-8.1
8.2-RELEASES
Test data:
-
Tue+1 TESTX 1
Tuesday+1 TESTX 2
* Tuesday+1 TESTX 3
On 2011-07-05, Julian H. Stacey wrote:
There's a regression error with calendar between FreeBSD-8.1 8.2-RELEASES
Test data:
-
Tue+1 TESTX 1
Tuesday+1 TESTX 2
* Tuesday+1 TESTX 3
Tuesday+1 * TESTX 4
Tuesday TESTX5
Tuesday TESTX6
On 2011-01-25, Jaakko Heinonen wrote:
Another related bug is in vfs_domount_update(): if VFS_MOUNT() succeeds
but vfs_export() fails, old mount flags and options are restored. I
think this shouldn't happen when VFS_MOUNT() has been already
successfully completed and this is the final reason
On 2011-01-19, Jaakko Heinonen wrote:
On 2011-01-19, Craig Rodrigues wrote:
I disagree with your patch and do not approve it.
1. Have mountd(8) running.
2. # mdconfig -a -t vnode -f ufsimg
3. # mount -o ro,rw /dev/md0 /mnt
With your patch[1] after the third step the mount point
On 2011-01-19, Craig Rodrigues wrote:
I disagree with your patch and do not approve it.
I prefer something simpler:
Thanks for your reply. However, your patch doesn't fix the bug(s) I
tried to resolve. See below.
ZFS can be changed to check for rw or noro.
It's possible but I don't like to
Hi,
Currently nmount(2) allows a mount point to have ro, rw, and noro
string options concurrently active. This can cause erratic behavior
demonstrated by this example:
1. Have mountd(8) running.
2. # mdconfig -a -t vnode -f ufsimg
3. # mount -o ro,rw /dev/md0 /mnt
After these steps the mount
On 2010-10-23, Garrett Cooper wrote:
The SF_ARCHIVED flag isn't noted in the chflags(2) ERROR section.
The attached patch adds the entry.
If no one has any objections, could someone help me commit this?
Index: lib/libc/sys/chflags.2
On 2010-10-06, Alexander Best wrote:
$ sudo rm -d /tmp/chflags.XX
$ tmpfile=`mktemp /tmp/chflags.XX`
$ sudo chflags arch $tmpfile
$ chflags noarch $tmpfile
is what's causing the problem. the last chflags call should fail, but it
doesn't.
Here is a patch for UFS:
%%%
Index:
On 2010-07-21, Bruce Evans wrote:
See PR kern/125009 (http://www.freebsd.org/cgi/query-pr.cgi?pr=125009).
I looked at the patches in the PR. It seems reasonable to require an X
but for VEXEC for all file types except directories, like I think the
vaccess() version of your patch does.
Hi,
On 2010-07-20, Garrett Cooper wrote:
I ran into an issue last night where apparently several apps make
faulty assumptions w.r.t. whether or not access(2) returns functional
data when running as a superuser.
New implementations are discouraged from returning X_OK unless at
least
Hi,
I wrote a patch to extend the kernel unit number allocator for
allocating specific unit numbers. The patch adds a new function
alloc_unr_specific() which returns the requested unit number if it is
free and -1 if the number is already allocated or out of the range.
Unlike alloc_unr(),
On 2010-03-05, Jaakko Heinonen wrote:
I have updated the patch taking some of bde's comments into account. The
new version also includes updates for namei(9) manual page.
Yet another update:
http://people.freebsd.org/~jh/patches/lookup-root.4.diff
I have committed the relookup() part
On 2010-03-10, Alexander Best wrote:
could this panic have been triggered by the patch?
It doesn't look like it's caused by the patch.
panic() at panic+0x15f
_mtx_lock_flags() at _mtx_lock_flags+0xc5
fdesc_allocvp() at fdesc_allocvp+0xbf
fdesc_lookup() at fdesc_lookup+0x15c
this was 100%
On 2010-03-11, Alexander Best wrote:
in sys/kern/vfs_syscalls.c:kern_rmdirat() there's still local code to check
for . and / after applying your patch. isn't this all being done by
calling namei() now?
Looking at it quickly I think that the . case is handled by lookup()
since r199137. However
On 2010-03-06, Garrett Cooper wrote:
http://people.freebsd.org/~jh/patches/lookup-root.2.diff
1. EBUSY's new definition doesn't look correct for rename(2) given
POSIX's definition (
http://www.opengroup.org/onlinepubs/009695399/functions/rename.html ):
[EBUSY]
[CX] [Option
On 2010-02-28, Jaakko Heinonen wrote:
http://people.freebsd.org/~jh/patches/lookup-root.diff
I have updated the patch taking some of bde's comments into account. The
new version also includes updates for namei(9) manual page.
The patch is attached to this mail and also found
[Moving discussion to -hackers. This is not directly related to the
original commit anymore.]
On 2010-02-26, Bruce Evans wrote:
http://people.freebsd.org/~jh/patches/lookup-root.diff
This is in relookup(). I think relookup() is only called from rename(),
so the failing case is
Hi,
I was looking to fix a bug (bin/95079) in apply(1) and found it easy to
fix it using a sbuf buffer. Does anyone see a problem with adding
libsbuf dependency for an utility such apply(1)? Nothing in usr.bin
seems to use libsbuf currently.
The patch:
On 2010-01-01, Jilles Tjoelker wrote:
On Fri, Jan 01, 2010 at 06:45:33PM +0100, Fernando Apesteguía wrote:
cat: /compat/linux/proc/cpuinfo: Input/output error
pfs_read() fails any read over MAXPHYS + 1 with EIO. This limit probably
has to do with the allocation of a buffer of that size
On 2009-06-15, Ivan Voras wrote:
Are there still known problems with tmpfs?
I think sendfile(2) is still broken on tmpfs. See:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/127213
--
Jaakko
___
freebsd-hackers@freebsd.org mailing list
Hi,
On 2008-12-10, Danny Braniss wrote:
from a solaris or linux client, doing a ls(1) of a nfs exported zfs
file,
for example: ls /net/zfs-server/h/.zfs/snapshot,
panics the server. The server is running latest 7.1-prerelease.
This has been reported as PR kern/125149. I have
On 2008-06-17, Gabor Kovesdan wrote:
egrep: empty (sub)expression
I've looked at this and I have a patch with a workaround:
http://kovesdan.org/patches/grep.dougb.diff
Unfortunately this breaks things. For example:
$ grep -E '(test||test)' /dev/null
grep: parentheses not balanced
$ grep
30 matches
Mail list logo
