On Fri, Nov 06, 2020 at 10:57:08PM +0800, Alex Shi wrote:
> The variable is unused and cause gcc warning:
> fs/coda/file.c:241:6: warning: variable ‘err’ set but not used
> [-Wunused-but-set-variable]
> So let's remove it.
> Signed-off-by: Alex Shi
> Cc: Jan Harkes
> Cc:
On Tue, Apr 28, 2020 at 03:09:51PM -0400, Jonathan Corbet wrote:
> So I'm happy to merge this set, but there is one thing that worries me a
> bit...
>
> > fs/coda/Kconfig |2 +-
>
> I'd feel a bit better if I could get an ack or two from filesystem folks
>
That looks good to me.
Acked-by: Jan Harkes
On April 18, 2019 10:06:07 AM EDT, David Howells wrote:
>- but, as the comment notes, this really needs some locking.
>
>Fix this by moving the core part of the code to fs/inode.c and
On Sun, Mar 31, 2019 at 03:13:47PM -0400, Jan Harkes wrote:
> On Sun, Mar 31, 2019 at 02:14:13PM -0400, Waiman Long wrote:
> > One possibility is that there is a previous reference to the memory
> > currently occupied by the spinlock. If the memory location is previously
>
On Sun, Mar 31, 2019 at 02:14:13PM -0400, Waiman Long wrote:
> On 03/31/2019 12:00 AM, Jan Harkes wrote:
> > On Fri, Mar 29, 2019 at 05:53:22PM +, Waiman Long wrote:
> >> On 03/29/2019 12:10 PM, Jan Harkes wrote:
> >>> I knew I definitely had never seen this
On Fri, Mar 29, 2019 at 05:53:22PM +, Waiman Long wrote:
> On 03/29/2019 12:10 PM, Jan Harkes wrote:
> > I knew I definitely had never seen this problem with the stable kernel
> > on Ubuntu xenial (4.4) so I bisected between v4.4 and v5.1-rc2 and ended
> > up at
> >
I was testing Coda on the 5.1-rc2 kernel and noticed that when I run a
binary out of /coda, the binary would never exit and the system would
detect a soft lockup. I narrowed it down to a very simple reproducible
case of running a statically linked executable (busybox) from /coda with
the cwd
On Thu, Feb 14, 2019 at 11:38:22AM +0300, Dan Carpenter wrote:
> The CODA_FREE() macro just calls kvfree(). We can call that directly
> instead.
Added these to my (getting long) list of things that I really should get
upstreamed sometime soon now.
Jan
This has come up before, and as you noticed nothing in that header is looked at
after that second copy.
Also if the user space cache manager was trying to be malicious it wouldn't
have to resort to multi-threaded race conditions. It could make a setuid root
shell appear, or many other things a
Same for Coda.
uid/gid/mode don't mean anything, access is based on the directory ACL and the
authentication token that is held by the userspace cache manager and ultimately
decided by the servers.
Unless someone broke this recently and made permission checks uid based I would
expect no
Same for Coda.
uid/gid/mode don't mean anything, access is based on the directory ACL and the
authentication token that is held by the userspace cache manager and ultimately
decided by the servers.
Unless someone broke this recently and made permission checks uid based I would
expect no
On Fri, Sep 28, 2018 at 09:00:48PM +0300, Amir Goldstein wrote:
> I chose not to split the patches per fs in the hope that maintainers
> would quickly ack the patch and ask you to carry it for them.
Ack for Coda. I actually have a patch queued somewhere that dropped
printing the name and only
On Fri, Sep 28, 2018 at 09:00:48PM +0300, Amir Goldstein wrote:
> I chose not to split the patches per fs in the hope that maintainers
> would quickly ack the patch and ask you to carry it for them.
Ack for Coda. I actually have a patch queued somewhere that dropped
printing the name and only
On Thu, Sep 06, 2018 at 01:52:29PM +0200, Yann Droneaud wrote:
> Hi,
>
> Le jeudi 06 septembre 2018 à 08:13 +0100, David Howells a écrit :
> > Yann Droneaud wrote:
> >
> > > This structure should not have been exposed to userspace in the
> > > first
> > > place: it's unusable by userspace as it
On Thu, Sep 06, 2018 at 01:52:29PM +0200, Yann Droneaud wrote:
> Hi,
>
> Le jeudi 06 septembre 2018 à 08:13 +0100, David Howells a écrit :
> > Yann Droneaud wrote:
> >
> > > This structure should not have been exposed to userspace in the
> > > first
> > > place: it's unusable by userspace as it
On Wed, Sep 05, 2018 at 07:12:37PM +0200, Yann Droneaud wrote:
> Le mercredi 05 septembre 2018 à 16:55 +0100, David Howells a écrit :
> > The size and layout of internal kernel structures may not be relied
> > upon outside of the kernel and may even change in a containerised
> > environment if a
On Wed, Sep 05, 2018 at 07:12:37PM +0200, Yann Droneaud wrote:
> Le mercredi 05 septembre 2018 à 16:55 +0100, David Howells a écrit :
> > The size and layout of internal kernel structures may not be relied
> > upon outside of the kernel and may even change in a containerised
> > environment if a
On Wed, Sep 05, 2018 at 04:55:10PM +0100, David Howells wrote:
> The size and layout of internal kernel structures may not be relied upon
> outside of the kernel and may even change in a containerised environment if
> a container image is frozen and shifted to another machine.
>
> Excise these
On Wed, Sep 05, 2018 at 04:55:10PM +0100, David Howells wrote:
> The size and layout of internal kernel structures may not be relied upon
> outside of the kernel and may even change in a containerised environment if
> a container image is frozen and shifted to another machine.
>
> Excise these
...@vger.kernel.org
Signed-off-by: Jan Harkes <jahar...@cs.cmu.edu>
---
fs/coda/upcall.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/coda/upcall.c b/fs/coda/upcall.c
index e82357c89979..8cf16d8c5261 100644
--- a/fs/coda/upcall.c
+++ b/fs/coda/upcall.c
@@ -446,8 +446,7
...@vger.kernel.org
Signed-off-by: Jan Harkes
---
fs/coda/upcall.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/coda/upcall.c b/fs/coda/upcall.c
index e82357c89979..8cf16d8c5261 100644
--- a/fs/coda/upcall.c
+++ b/fs/coda/upcall.c
@@ -446,8 +446,7 @@ int venus_fsync(struct
On Sat, Sep 23, 2017 at 10:35:45PM -0400, Meng Xu wrote:
> Hi Jaharkes and Coda filesystem developers,
>
> I am resending the email on a potential race condition bug I found in the
> Coda filesystem as well as the patch I propose. Please feel free to comment
> whether you think this is a serious
On Sat, Sep 23, 2017 at 10:35:45PM -0400, Meng Xu wrote:
> Hi Jaharkes and Coda filesystem developers,
>
> I am resending the email on a potential race condition bug I found in the
> Coda filesystem as well as the patch I propose. Please feel free to comment
> whether you think this is a serious
to userspace. If we want to avoid
context switches, disk I/O and only check on what happens to be cached
in the kernel the current approach works fine.
Jan
> Signed-off-by: Miklos Szeredi <mszer...@redhat.com>
> Cc: Jan Harkes <jahar...@cs.cmu.edu>
> ---
> fs/coda/inode.
to userspace. If we want to avoid
context switches, disk I/O and only check on what happens to be cached
in the kernel the current approach works fine.
Jan
> Signed-off-by: Miklos Szeredi
> Cc: Jan Harkes
> ---
> fs/coda/inode.c | 5 -
> 1 file changed, 4 insertions(+), 1 del
On Wed, Aug 02, 2017 at 11:05:31AM -0400, Jeff Layton wrote:
> The weird bit is that in coda_file_mmap, we then do this:
>
> coda_file->f_mapping = host_file->f_mapping;
> if (coda_inode->i_mapping == _inode->i_data)
> coda_inode->i_mapping = host_inode->i_mapping;
On Wed, Aug 02, 2017 at 11:05:31AM -0400, Jeff Layton wrote:
> The weird bit is that in coda_file_mmap, we then do this:
>
> coda_file->f_mapping = host_file->f_mapping;
> if (coda_inode->i_mapping == _inode->i_data)
> coda_inode->i_mapping = host_inode->i_mapping;
On Sat, May 30, 2015 at 05:39:28PM +0200, Mikko Rapeli wrote:
> Include linux/coda.h for caddr_t and use unsigned short type directly.
> Userspace headers do not have list_head and wait_queue_head_t so just
> ifdef them away which is a HACK. Any ideas how to fix this properly?
I grepped the Coda
On Sat, May 30, 2015 at 05:39:28PM +0200, Mikko Rapeli wrote:
Include linux/coda.h for caddr_t and use unsigned short type directly.
Userspace headers do not have list_head and wait_queue_head_t so just
ifdef them away which is a HACK. Any ideas how to fix this properly?
I grepped the Coda
On Mon, Apr 27, 2015 at 07:23:06PM +0200, Fabian Frederick wrote:
> Move UPARG code to alloc_upcall() and test errors/return in callsites.
> This patch removes flow control in macros which must be avoided.
> (See Documentation/CodingStyle)
At first glance this is not a correct patch.
UPARG
On Mon, Apr 27, 2015 at 07:23:06PM +0200, Fabian Frederick wrote:
Move UPARG code to alloc_upcall() and test errors/return in callsites.
This patch removes flow control in macros which must be avoided.
(See Documentation/CodingStyle)
At first glance this is not a correct patch.
UPARG
On Tue, May 13, 2014 at 06:49:09PM +0200, Fabian Frederick wrote:
> No level printk converted to pr_warn or pr_info
>
> Cc: Jan Harkes
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
> ---
Ack, those are nice cleanups for those ugly printk's. Looks like it will
On Tue, May 13, 2014 at 06:49:09PM +0200, Fabian Frederick wrote:
No level printk converted to pr_warn or pr_info
Cc: Jan Harkes jahar...@cs.cmu.edu
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Fabian Frederick f...@skynet.be
---
Ack, those are nice cleanups for those ugly
On Wed, Feb 13, 2013 at 09:51:07AM -0800, Eric W. Biederman wrote:
> From: "Eric W. Biederman"
>
> Remove the slight chance that uids and gids in coda messages will be
> interpreted in the wrong user namespace.
Awesome, I was wondering how to handle uid's from different namespaces
cleanly in
On Wed, Feb 13, 2013 at 09:51:07AM -0800, Eric W. Biederman wrote:
From: Eric W. Biederman ebied...@xmission.com
Remove the slight chance that uids and gids in coda messages will be
interpreted in the wrong user namespace.
Awesome, I was wondering how to handle uid's from different
On Wed, Feb 13, 2008 at 02:22:43PM +0200, Ilpo J?rvinen wrote:
> They're defined later on in the same file with bodies and
> nothingin between needs them.
>
> Signed-off-by: Ilpo J?rvinen <[EMAIL PROTECTED]>
Acked-by: Jan Harkes <[EMAIL PROTECTED]>
Looks good, getting rid
On Fri, Feb 08, 2008 at 12:14:40AM +0100, Rafael J. Wysocki wrote:
> I haven't revert the changes. It's only moved the notifier chain calls from
> the ioctls to open/release in user.c .
Ah my bad, sorry about the false alarm.
Jan
--
To unsubscribe from this list: send the line "unsubscribe
On Fri, Feb 01, 2008 at 06:20:56PM -0500, Len Brown wrote:
> please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git suspend
>
> This will update the files shown below.
The following patch,
commit c3e94d899c864e558f938f9845ddb8c2e5d5ccd0
Author:
On Fri, Feb 01, 2008 at 06:20:56PM -0500, Len Brown wrote:
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git suspend
This will update the files shown below.
The following patch,
commit c3e94d899c864e558f938f9845ddb8c2e5d5ccd0
Author: Alan
On Fri, Feb 08, 2008 at 12:14:40AM +0100, Rafael J. Wysocki wrote:
I haven't revert the changes. It's only moved the notifier chain calls from
the ioctls to open/release in user.c .
Ah my bad, sorry about the false alarm.
Jan
--
To unsubscribe from this list: send the line unsubscribe
On Sat, Oct 27, 2007 at 11:34:26AM +0200, Peter Zijlstra wrote:
> I had me a little look at bdi usage in networked filesystems.
>
> NFS, CIFS, (smbfs), AFS, CODA and NCP
>
> And of those, NFS is the only one that I could find that creates
> backing_dev_info structures. The rest seems to fall
On Sat, Oct 27, 2007 at 11:34:26AM +0200, Peter Zijlstra wrote:
I had me a little look at bdi usage in networked filesystems.
NFS, CIFS, (smbfs), AFS, CODA and NCP
And of those, NFS is the only one that I could find that creates
backing_dev_info structures. The rest seems to fall back to
the setattr inode op.
>
> Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
Coda part looks fine to me. Couldn't test it beyond 'it compiles and
doesn't oops', because our userspace client unconditionally strips
setuid/setgid bits anyways.
Acked-by: Jan Harkes <[EMAIL PROTECTED]>
-
op.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
Coda part looks fine to me. Couldn't test it beyond 'it compiles and
doesn't oops', because our userspace client unconditionally strips
setuid/setgid bits anyways.
Acked-by: Jan Harkes [EMAIL PROTECTED]
-
To unsubscribe from this list: send
On Mon, Jul 16, 2007 at 09:49:30PM +0100, Al Viro wrote:
> > c) Jan's patch was not cc'ed to any mailing list
>
> ... said patch (presumably being an obvious fix of obvious roothole)
> had not been sent to mainline immediately.
The exploiting application would have to run in the role of the
On Mon, Jul 16, 2007 at 01:44:24PM -0700, Andrew Morton wrote:
> On Sun, 15 Jul 2007 23:59:03 GMT
> Linux Kernel Mailing List wrote:
> >
> > wrong order of arguments of ->readdir()
> >
> > Shows how many people are testing coda - the bug had been there for 5
> > years
> > and
On Mon, Jul 16, 2007 at 01:44:24PM -0700, Andrew Morton wrote:
On Sun, 15 Jul 2007 23:59:03 GMT
Linux Kernel Mailing List linux-kernel@vger.kernel.org wrote:
wrong order of arguments of -readdir()
Shows how many people are testing coda - the bug had been there for 5
On Mon, Jul 16, 2007 at 09:49:30PM +0100, Al Viro wrote:
c) Jan's patch was not cc'ed to any mailing list
... said patch (presumably being an obvious fix of obvious roothole)
had not been sent to mainline immediately.
The exploiting application would have to run in the role of the
On Wed, Jun 27, 2007 at 08:08:08PM -0300, Alexandre Oliva wrote:
> On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:
>
> > GPLv2 section 3.
> > The source code for a work means the preferred form of the work for
> > making modifications to it
On Wed, Jun 27, 2007 at 08:08:08PM -0300, Alexandre Oliva wrote:
On Jun 26, 2007, Jan Harkes [EMAIL PROTECTED] wrote:
GPLv2 section 3.
The source code for a work means the preferred form of the work for
making modifications to it.
I believe this states that the source code has
On Tue, Jun 26, 2007 at 04:47:34AM -0300, Alexandre Oliva wrote:
> On Jun 26, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> > On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:
> >> You could argue that they do not restrict copying, distribution
> &
On Tue, Jun 26, 2007 at 04:47:34AM -0300, Alexandre Oliva wrote:
On Jun 26, 2007, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Jun 26, 2007, Jan Harkes [EMAIL PROTECTED] wrote:
You could argue that they do not restrict copying, distribution
and modification of the sources in general, only
On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote:
> Consider this scenario: vendor tivoizes Linux in the device, and
> includes the corresponding sources only in a partition that is
> theoretically accessible using the shipped kernel, but that nothing in
> the software available in
On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote:
Consider this scenario: vendor tivoizes Linux in the device, and
includes the corresponding sources only in a partition that is
theoretically accessible using the shipped kernel, but that nothing in
the software available in the
On Fri, Jun 22, 2007 at 01:14:27AM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> >> It's not like anyone can safely tivoize devices with GPLv2 already,
>
&
On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
>
> >> > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't
> >> > I take any
> >> > GPLv3 program, combine it with a few lines of Linux code, and
> >> >
On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
On Jun 21, 2007, David Schwartz [EMAIL PROTECTED] wrote:
Wouldn't that defeat the entire purpose of the GPLv3? Couldn't
I take any
GPLv3 program, combine it with a few lines of Linux code, and
Tivoize the
result?
On Fri, Jun 22, 2007 at 01:14:27AM -0300, Alexandre Oliva wrote:
On Jun 21, 2007, Jan Harkes [EMAIL PROTECTED] wrote:
On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
It's not like anyone can safely tivoize devices with GPLv2 already,
So you really didn't pay any
On Tue, Jun 19, 2007 at 06:20:24PM -0300, Alexandre Oliva wrote:
> On Jun 19, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:
> > and which will most likely make GPLv3 software unusable for various
> > applications ranging from medical equipment to financial transaction
>
On Tue, Jun 19, 2007 at 03:13:33PM -0700, H. Peter Anvin wrote:
> [EMAIL PROTECTED] wrote:
> >
> > the only trouble I ever had with the .snapshot approach is when tar or
> > find would decend down into the .snapshot when I didn't really intend
> > for it to do so.
> >
>
> Netapp optionally made
On Tue, Jun 19, 2007 at 02:40:59AM -0300, Alexandre Oliva wrote:
> > The actual software is mailed to you on a credit card sized
> > ROM when you activate service.
...
> The GPLv3 won't remove every way in which people who want/need to stop
> the user from making changes to the software could
On Tue, Jun 19, 2007 at 02:40:59AM -0300, Alexandre Oliva wrote:
The actual software is mailed to you on a credit card sized
ROM when you activate service.
...
The GPLv3 won't remove every way in which people who want/need to stop
the user from making changes to the software could
On Tue, Jun 19, 2007 at 03:13:33PM -0700, H. Peter Anvin wrote:
[EMAIL PROTECTED] wrote:
the only trouble I ever had with the .snapshot approach is when tar or
find would decend down into the .snapshot when I didn't really intend
for it to do so.
Netapp optionally made .snapshot
On Tue, Jun 19, 2007 at 06:20:24PM -0300, Alexandre Oliva wrote:
On Jun 19, 2007, Jan Harkes [EMAIL PROTECTED] wrote:
and which will most likely make GPLv3 software unusable for various
applications ranging from medical equipment to financial transaction
systems (and probably others
On Mon, Jun 18, 2007 at 08:31:30PM -0300, Alexandre Oliva wrote:
> On Jun 18, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > In the GPLv3 world, we have already discussed in this thread how you can
> > follow the GPLv3 by making the TECHNICALLY INFERIOR choice of using a ROM
> > instead of
On Mon, Jun 18, 2007 at 08:31:30PM -0300, Alexandre Oliva wrote:
On Jun 18, 2007, Linus Torvalds [EMAIL PROTECTED] wrote:
In the GPLv3 world, we have already discussed in this thread how you can
follow the GPLv3 by making the TECHNICALLY INFERIOR choice of using a ROM
instead of using a
On Sun, Jun 17, 2007 at 05:17:57AM -0300, Alexandre Oliva wrote:
> Just make the tivoization machinery require two keys: one that the
> vendor keeps, one that the vendor gives to the user (maybe without
> ever knowing it). Neither one can install modifications alone, but
> the user can approve
On Sun, Jun 17, 2007 at 05:17:57AM -0300, Alexandre Oliva wrote:
Just make the tivoization machinery require two keys: one that the
vendor keeps, one that the vendor gives to the user (maybe without
ever knowing it). Neither one can install modifications alone, but
the user can approve
On Sat, Jun 16, 2007 at 02:03:49PM -0600, Jeffrey V. Merkey wrote:
> Jan Harkes wrote:
> >implementation, just a high level description. Finally advising anyone
> >(who is not an actual patent lawyer that could correctly interpret the
> >language and scope of a patent) to
On Sat, Jun 16, 2007 at 04:12:14AM -0600, Jeffrey V. Merkey wrote:
> Jeffrey V. Merkey wrote:
> >over). There's also another patent filed as well. It's a noble
> >effort to do a free version, but be aware there's some big guns with
> >patents out there already, not to mention doing this is
On Sat, Jun 16, 2007 at 04:12:14AM -0600, Jeffrey V. Merkey wrote:
Jeffrey V. Merkey wrote:
over). There's also another patent filed as well. It's a noble
effort to do a free version, but be aware there's some big guns with
patents out there already, not to mention doing this is complex
On Sat, Jun 16, 2007 at 02:03:49PM -0600, Jeffrey V. Merkey wrote:
Jan Harkes wrote:
implementation, just a high level description. Finally advising anyone
(who is not an actual patent lawyer that could correctly interpret the
language and scope of a patent) to go search out patents seems
On Fri, Jun 15, 2007 at 12:02:11PM +0200, Bernd Paysan wrote:
> > the GPLv3 license. That's not their fault, it's the fault of people
> > who wrote the GPLv3 license, promulgated the GPLv3 license, and who is
> > attempting to convince everyone that the GPLv3 license is the only
> > valid license
On Fri, Jun 15, 2007 at 12:02:11PM +0200, Bernd Paysan wrote:
the GPLv3 license. That's not their fault, it's the fault of people
who wrote the GPLv3 license, promulgated the GPLv3 license, and who is
attempting to convince everyone that the GPLv3 license is the only
valid license for
On Thu, Jun 14, 2007 at 12:28:34PM -0700, David Schwartz wrote:
> > The GPL applies to "the Program" which in this case is the Linux kernel
> > as a whole and it in fact does indicate a specific version. All code
> > submitted and included in this program has has been submitted with the
> >
On Thu, Jun 14, 2007 at 12:28:34PM -0700, David Schwartz wrote:
The GPL applies to the Program which in this case is the Linux kernel
as a whole and it in fact does indicate a specific version. All code
submitted and included in this program has has been submitted with the
understanding
On Wed, Jun 13, 2007 at 04:24:36PM +0200, Bernd Paysan wrote:
> There's no point of discussing that the Linux kernel *as a whole* (as
> compilation) currently is under GPLv2 only, since it sais so, and a few
> files also explicitely say so. The whole combination is GPLv2 only, but
> most parts
On Wed, Jun 13, 2007 at 04:24:36PM +0200, Bernd Paysan wrote:
There's no point of discussing that the Linux kernel *as a whole* (as
compilation) currently is under GPLv2 only, since it sais so, and a few
files also explicitely say so. The whole combination is GPLv2 only, but
most parts
Since you decide to publically respond to a private email, but not only
you did not 'discuss' anything I wrote and in fact cut out most of the
useful information in my reply I guess I will have to repeat my
observations.
Once I send out this email, I'll just add you to my friendly killfile
(as
Since you decide to publically respond to a private email, but not only
you did not 'discuss' anything I wrote and in fact cut out most of the
useful information in my reply I guess I will have to repeat my
observations.
Once I send out this email, I'll just add you to my friendly killfile
(as
On Mon, Jan 01, 2007 at 11:47:06PM +0100, Mikulas Patocka wrote:
> >Anyway, cp -a is not the only application that wants to do hardlink
> >detection.
>
> I tested programs for ino_t collision (I intentionally injected it) and
> found that CP from coreutils 6.7 fails to copy directories but
On Mon, Jan 01, 2007 at 11:47:06PM +0100, Mikulas Patocka wrote:
Anyway, cp -a is not the only application that wants to do hardlink
detection.
I tested programs for ino_t collision (I intentionally injected it) and
found that CP from coreutils 6.7 fails to copy directories but displays
On Fri, Dec 22, 2006 at 12:49:42AM +0100, Mikulas Patocka wrote:
> On Thu, 21 Dec 2006, Jan Harkes wrote:
> >On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
> >>The stat64.st_ino field is 64bit, so AFAICS you'd only need to extend
> >>the kstat.ino f
On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
> The stat64.st_ino field is 64bit, so AFAICS you'd only need to extend
> the kstat.ino field to 64bit and fix those filesystems to fill in
> kstat correctly.
Coda actually uses 128-bit file identifiers internally, so 64-bits
really
On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
The stat64.st_ino field is 64bit, so AFAICS you'd only need to extend
the kstat.ino field to 64bit and fix those filesystems to fill in
kstat correctly.
Coda actually uses 128-bit file identifiers internally, so 64-bits
really
On Fri, Dec 22, 2006 at 12:49:42AM +0100, Mikulas Patocka wrote:
On Thu, 21 Dec 2006, Jan Harkes wrote:
On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
The stat64.st_ino field is 64bit, so AFAICS you'd only need to extend
the kstat.ino field to 64bit and fix those filesystems
On Wed, Jul 06, 2005 at 09:33:13PM -0500, David Masover wrote:
> And speaking of which, the only doomsday scenario (running out of RAM)
> that I can think of with this scheme is if we have a ton of hardlinks to
> the same file and we try to move one of them. But this scales linearly
> with the
On Wed, Jul 06, 2005 at 09:33:13PM -0500, David Masover wrote:
And speaking of which, the only doomsday scenario (running out of RAM)
that I can think of with this scheme is if we have a ton of hardlinks to
the same file and we try to move one of them. But this scales linearly
with the
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
> In the not-too distant past, one could disable Ctl-Alt-DEL.
> Can't do it anymore.
...
> Observe that reboot() returns 0 and `strace` understands what
> parameters were passed. The result is that, if I hit Ctl-Alt-Del,
> `init`
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
...
Observe that reboot() returns 0 and `strace` understands what
parameters were passed. The result is that, if I hit Ctl-Alt-Del,
`init` will
On Tue, Apr 05, 2005 at 10:45:30PM +0200, Kay Sievers wrote:
> On Tue, 2005-04-05 at 15:38 -0400, Jan Harkes wrote:
> > Here is another stab at making the keyspan firmware easily loadable with
> > hotplug. Differences from the previous version,
> >
> > - keep the
Simple program to convert the keyspan firmware header files to IHEX
formatted files that can be loaded with hotplug.
This is really only needed once to convert the existing keyspan firmware
headers, which is what the next patch does.
Index: linux/drivers/usb/serial/dumpfw.c
Add "make install_firmware" to the kbuild environment.
Signed-off-by: Jan Harkes <[EMAIL PROTECTED]>
Makefile| 33 +
drivers/usb/serial/Makefile |5 +
scripts/Makefile.fwinst | 34 +++
Convert the keyspan USB serial driver to use request_firmware and
firmware_load_ihex.
Signed-off-by: Jan Harkes <[EMAIL PROTECTED]>
Kconfig | 90 --
keyspan.c | 132 +++---
keyspan.h
A simple Intel HEX format parser/loader.
Signed-off-by: Jan Harkes <[EMAIL PROTECTED]>
include/linux/ihex_parser.h | 23 +
lib/Kconfig |8 +
lib/Makefile|2
lib/ihex_parser.c | 181
4
Here is another stab at making the keyspan firmware easily loadable with
hotplug. Differences from the previous version,
- keep the IHEX parser into a separate module.
- added a fw-y and fw-m install targets to kbuild which will install a
driver's firmware files in /lib/modules/`uname
On Tue, Apr 05, 2005 at 04:36:31PM +0200, Marcel Holtmann wrote:
> > > I agree with Dmitry on this point. The IHEX parser should not be inside
> > > firmware_class.c. What about using keyspan_ihex.[ch] for it?
> >
> > That's what I had originally, actually called firmware_ihex.ko, since
> > the
On Tue, Apr 05, 2005 at 11:22:06AM +0200, Marcel Holtmann wrote:
> I agree with Dmitry on this point. The IHEX parser should not be inside
> firmware_class.c. What about using keyspan_ihex.[ch] for it?
That's what I had originally, actually called firmware_ihex.ko, since
the IHEX format parser is
On Tue, Apr 05, 2005 at 10:32:38AM +0200, Kay Sievers wrote:
> On Mon, 2005-04-04 at 23:51 -0500, Dmitry Torokhov wrote:
> > Firmware loader is format-agnostic, I think having IHEX parser in a separate
> > file would be better...
>
> Why should this be in-kernel at all? Convert the firmware into
A simple Intel HEX format parser/loader.
Signed-off-by: Jan Harkes [EMAIL PROTECTED]
include/linux/ihex_parser.h | 23 +
lib/Kconfig |8 +
lib/Makefile|2
lib/ihex_parser.c | 181
4 files
1 - 100 of 166 matches
Mail list logo
