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 mo
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
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
>
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
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 TESTXX
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+
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
valid
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 vers
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
http://lists.freebsd.org/mailman/listinfo/fre
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 did
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 so
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
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
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:
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(), alloc_un
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
> l
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.
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-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 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
$ g
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 descr
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
http://lists
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 s
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:
http://people.freebsd.org/~jh/patc
[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 unrea
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
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
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 wa
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.
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 t
30 matches
Mail list logo
