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, gettin
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 linux
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 Cod
On Thu, Apr 12, 2001 at 01:45:08AM -0400, Alexander Viro wrote:
> On Wed, 11 Apr 2001, Andreas Dilger wrote:
>
> > I just discovered a similar problem when testing Daniel Philip's new ext2
> > directory indexing code with bonnie++. I was running bonnie under single
> > user mode (basically nothi
On Thu, Apr 19, 2001 at 02:27:48AM +0200, Daniel Phillips wrote:
> more memory. If you have enough memory, the inode cache won't thrash,
> and even when it does, it does so gracefully - performance falls off
> nice and slowly. For example, 250 Meg of inode cache will handle 2
> million inodes wi
On Mon, Apr 23, 2001 at 10:45:05PM +0200, Ingo Oeser wrote:
> Last time we suggested this, people ended up with some OS trying
> it and getting worse performance.
>
> Why? You need to allocate the VFS-inode (vnode in other OSs) and
> the on-disk-inode anyway at the same time. You get better
> pe
On Mon, Nov 06, 2000 at 10:35:39AM +0100, Pavel Machek wrote:
> Hi!
>
> It complains
>
> coda_read_super: Bad mount data
> coda_read_super: device index: 0
>
> and will not mount. What do I need to mount coda?
> Pavel
Miklos Szeredi
On Fri, Nov 10, 2000 at 08:27:47PM +0100, Rafal Maszkowski wrote:
> On Thu, Nov 09, 2000 at 05:52:29PM -0800, Linus Torvalds wrote:
> > - pre2:
> > - David Miller: sparc64 updates, make sparc32 boot again
>
> Thanks for working on it but I am getting still:
>
> boot: 11.2
> Uncompressing im
On Fri, Nov 10, 2000 at 10:48:08PM +0100, Pavel Machek wrote:
> Hi!
>
> I found where problem with coda lies: it went from character device at
> 67:5 to character device at 67:0. Ouch, ugly. Is it bug or what?
> Pavel
No, it always ha
On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> Greetings,
>
> I have a server farm made of identical hardware running pop3 and imap mail
> functions. recently, we upgraded all the machines to kernel 2.4.2, but we
> noticed that according to free, our memory utilization went way up.
On Wed, Mar 21, 2001 at 11:42:08AM -0600, Josh Grebe wrote:
> This is what I'm afraid of, in my case we have millions of files that are
> dealt with in no real order, and if cache fragmentation will keep the
> memory from being freed, we're in for problems. This reading was taken
> with the machin
I found some code that seems wrong and didn't even match it's comment.
Patch is against 2.4.2, but should go cleanly against 2.4.3-pre6 as well.
Jan
--- linux/fs/inode.c.orig Thu Mar 22 13:20:55 2001
+++ linux/fs/inode.cThu Mar 22 13:21:32 2001
@@ -133,7 +133,7 @@
if (sb) {
On Thu, Mar 22, 2001 at 07:04:52PM +, Stephen C. Tweedie wrote:
> Hi,
>
> On Thu, Mar 22, 2001 at 01:42:15PM -0500, Jan Harkes wrote:
> >
> > I found some code that seems wrong and didn't even match it's comment.
> > Patch is against 2.4.2, but should
On Fri, Mar 23, 2001 at 10:13:55AM -0500, Jeff Garzik wrote:
> Personally I think the OOM killer itself is fine. I think there are
> problems elsewhere which are triggering the OOM killer when it should
> not be triggered, ie. a leak like Doug Ledford was reporting.
>
> I definitely see heavier
On Fri, Mar 23, 2001 at 05:17:16PM +0100, Andi Kleen wrote:
> On Fri, Mar 23, 2001 at 05:10:56PM +0100, Jan Harkes wrote:
> > btw. There definitely is a network receive buffer leak somewhere in
> > either the 3c905C path or higher up in the network layers (2.4.0 or
> > 2.
On Tue, Mar 27, 2001 at 09:15:08AM -0800, LA Walsh wrote:
> Now lets look at the sites want to process terabytes of
> data -- perhaps files systems up into the Pentabyte range. Often I
> can see these being large multi-node (think 16-1024 clusters as
> are in use today for large super-clus
On Tue, Mar 27, 2001 at 01:57:42PM -0600, Jesse Pollard wrote:
> > Using similar numbers as presented. If we are working our way through
> > every single block in a Pentabyte filesystem, and the blocksize is 512
> > bytes. Then the 1us in extra CPU cycles because of 64-bit operations
> > would add
On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> >
> > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> >
> > Can you summarize the con
Adding firmware_load_ihex, to load IHEX formatted firmware images.
Signed-off-by: Jan Harkes <[EMAIL PROTECTED]>
drivers/base/firmware_class.c | 151 ++
include/linux/firmware.h | 26 +++
2 files changed, 177 insertions(+)
Index:
Convert the keyspan USB serial driver to use request_firmware and
firmware_load_ihex.
Signed-off-by: Jan Harkes <[EMAIL PROTECTED]>
Index: linux/drivers/usb/serial/keyspan.c
===
--- linux.orig/drivers/usb/serial/keyspan.c
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 will do.
Signed-off-by: Jan Harkes <[EMAIL PROTECTED]>
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
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 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 IH
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 -r`/firmw
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
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 +++
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
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
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` w
On Mon, May 21, 2001 at 09:24:20PM -0700, Me wrote:
> Coda.h assumes that __KERNEL__ can only be defined if __linux__ is, which is
> painfully false. This allows the kernel compile to get farther on my token
> FreeBSD box.
>
> -Ryan
Are you trying to compile a Linux kernel on a FreeBSD machin
On Tue, May 22, 2001 at 09:40:19AM -0700, Ryan Cumming wrote:
> On Tue, 22 May 2001, Alan Cox wrote:
>
> > If __linux__ is not defined by the cross compiler, then the cross compiler
> > is broken. A cross compiler has the same environment as the native compiler
> > for the target. The only stuff
On Mon, May 21, 2001 at 03:10:32PM -0700, Linus Torvalds wrote:
> That, in turn, might be as simple as changing the ioctl incoming arguments
> of into a structure like .
At least make sure that the 'kioctl' returns the number of bytes placed
into the output buffer, as userspace doesn't necessari
On Tue, May 22, 2001 at 04:57:24PM +0100, David Woodhouse wrote:
> The kernel compiles quite happily with compilers which aren't targetted
> specifically at Linux -- the CODA compatibility cruft being the one
> exception. I often just comment out the CODA includes from to
> get round the same
On Wed, Jun 06, 2001 at 12:42:03PM -0600, Eric W. Biederman wrote:
> Jeff Garzik <[EMAIL PROTECTED]> writes:
> > I'm sorry but this is a regression, plain and simple.
> >
> > Previous versons of Linux have worked great on diskless workstations
> > with NO swap.
> >
> > Swap is "extra space to be
On Thu, Jun 07, 2001 at 01:37:50PM +0200, Jan Kasprzak wrote:
> The goal is to speed-up reading of potentially slow filesystems
> (NFS, maybe even CD-based ones) by the local on-disk cache in the same way
> IRIX or Solaris CacheFS works. I would expect this to be used on clusters
> of comput
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, Sep 19, 2001 at 10:23:36AM -0400, Sujal Shah wrote:
> The Linux Coda drivers and the ext3 patches don't seem to get along
> very well, at least in Linux 2.4.7. I've got a stock 2.4.7 kernel with
The attached patch should fix it. I haven't tested it against ext3, but
with tmpfs which
On Thu, Sep 20, 2001 at 01:38:26PM +0100, Florian Schaefer wrote:
> On Wed, 19 Sep 2001 21:37:14 -0400, Jan Harkes said:
> >On Wed, Sep 19, 2001 at 10:23:36AM -0400, Sujal Shah wrote:
> > > The Linux Coda drivers and the ext3 patches don't seem to get along
> > &
On Wed, Sep 19, 2001 at 10:23:36AM -0400, Sujal Shah wrote:
> The Linux Coda drivers and the ext3 patches don't seem to get along
> very well, at least in Linux 2.4.7. I've got a stock 2.4.7 kernel with
> a patch applied to the USB drivers (for a sony digital camera; see
> http://www.sujal.n
On Tue, May 15, 2001 at 11:04:27AM -0700, Linus Torvalds wrote:
> And using ASCII names ("eject") instead of numbers (see the "FDEJECT" and
> "CDROMEJECT" etc #defines) sure as hell makes for easier maintenance and
> avoids the whole issue of maintaining static numbers (all the same things
> that
On Tue, May 15, 2001 at 02:02:29PM -0700, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Alexander Viro <[EMAIL PROTECTED]> wrote:
> >On Tue, 15 May 2001, H. Peter Anvin wrote:
> >
> >> Alexander Viro wrote:
> >> > >
> >> > > None whatsoever. The one thing that matters is that noone s
On Fri, Mar 25, 2005 at 02:59:14PM +0100, Jesper Juhl wrote:
> On Thu, 24 Mar 2005, H. Peter Anvin wrote:
> > Note that Linux always accepts . and .. so it's just a matter of making them
> > appear in readdir.
> >
> I'm working on that, but it's a learning experience for me, so it's going
> a bit
On Wed, Mar 30, 2005 at 12:39:07PM -0800, Andrew Morton wrote:
> Russ Weight <[EMAIL PROTECTED]> wrote:
> > This patch sets the MS_ACTIVE bit in isofs_fill_super() prior to calling
> > iget() or iput(). This eliminates a race condition between mount
> > (for isofs) and kswapd that results in a syst
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 bac
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 d
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.
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 displa
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 u
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 accom
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 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 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
> >> > Tivo
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,
&g
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 t
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 a
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
> > underst
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 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 comp
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 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 mod
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 re
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
user
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 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.
>
&
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 we
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 prin
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 change
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 <[EMA
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 alloca
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 u
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 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 wil
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
> befor
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
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 outsid
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
> >
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 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 fro
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 co
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 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
>
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 p
...@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
te the flag up 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 inser
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 == &coda_inode->i_data)
> coda_inode->i_mapping = host_inode->i_mapp
90 matches
Mail list logo
