On Tue, Apr 20, 2021 at 09:15:23AM +0200, Greg KH wrote:
> If you look at the code, this is impossible to have happen.
>
> Please stop submitting known-invalid patches. Your professor is playing
> around with the review process in order to achieve a paper in some
> strange and bizarre way.
>
>
On Tue, Apr 06, 2021 at 07:16:56PM -0500, Aditya Pakki wrote:
> In gss_pipe_destroy_msg(), in case of error in msg, gss_release_msg
> deletes gss_msg. The patch adds a check to avoid a potential double
> free.
We're already dereferenced msg. Nothing has set gss_msg to NULL. It's
the
On 4/7/2021 07:48, Corentin Labbe wrote:
Le Wed, Apr 07, 2021 at 07:28:26AM -0700, Bruce Mitchell a écrit :
On 4/7/2021 07:23, Corentin Labbe wrote:
Le Wed, Apr 07, 2021 at 07:13:04AM -0700, Bruce Mitchell a écrit :
On 4/7/2021 05:54, Corentin Labbe wrote:
Hello
I try to do kexec
On 4/7/2021 07:23, Corentin Labbe wrote:
Le Wed, Apr 07, 2021 at 07:13:04AM -0700, Bruce Mitchell a écrit :
On 4/7/2021 05:54, Corentin Labbe wrote:
Hello
I try to do kexec on a cortina/gemini SoC.
On a "normal" boot, kexec fail to find memory so I added crashkernel=8M to
cmdlin
an-ongoing-saga/
Here is the kernel command line reference
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt?h=v5.11#n732
I feel your frustrations too.
--
Bruce
just that.
>
> Likewise, re-initializing nfsd_drc_mem_used is probably not good
> to do either, but clobbering a spinlock like that might lead to
> a crash.
>
> Bruce, any further thoughts?
The other nfsd_drc_lock users run in nfsd threads, which shouldn't be
running yet at the po
> > >
> > > > Greg Kroah-Hartman wrote:
> > > > > J. Bruce Fields (2):
> > > > > Revert "nfsd4: remove check_conflicting_opens warning"
> > > > > Revert "nfsd4: a client's own opens needn't prevent delegati
On 3/22/2021 09:40, Bruce Mitchell wrote:
On 3/22/2021 08:57, Bruce Mitchell wrote:
These callbacks are required for kexec to function. The AST2600 does not
expose any controls for powering down it's CPU cores, so we borrow the
approach taken from socfpga and wait in the idle loop.
Author
d
> > outputs it in various formats is also a possible solution. For now, it
> > seems reasonable to put this here since this particular code path is the
> > one that has repeatedly come up in production.
> >
> > Signed-off-by: Chris Down
> > Cc: Chuck Lever
> >
On Mon, Mar 08, 2021 at 09:13:55AM +, David Howells wrote:
> Amir Goldstein wrote:
> > With ->fiemap() you can at least make the distinction between a non existing
> > and an UNWRITTEN extent.
>
> I can't use that for XFS, Ext4 or btrfs, I suspect. Christoph and Dave's
> assertion is that
Adding Chuck, linux-nfs.
Makes sense to me.--b.
On Fri, Feb 26, 2021 at 09:38:20AM -0500, Joe Korty wrote:
> Repair misuse of sv_lock in 5.10.16-rt30.
>
> [ This problem is in mainline, but only rt has the chops to be
> able to detect it. ]
>
> Lockdep reports a circular lock dependency
On Wed, Feb 24, 2021 at 03:35:44AM -0500, Luo Longjun wrote:
> @@ -2912,17 +2922,66 @@ static int locks_show(struct seq_file *f, void *v)
> struct file_lock *fl, *bfl;
> struct pid_namespace *proc_pidns =
> proc_pid_ns(file_inode(f->file)->i_sb);
>
> + struct list_head root;
> +
On Sun, Feb 21, 2021 at 01:43:03PM -0500, Jeff Layton wrote:
> On Sun, 2021-02-21 at 16:52 +, Al Viro wrote:
> > On Sat, Feb 20, 2021 at 01:32:50AM -0500, Luo Longjun wrote:
> > > + list_for_each_entry(bfl, >fl_blocked_requests, fl_blocked_member)
> > > + __locks_show(f, bfl, level +
On Sun, Feb 21, 2021 at 11:38:51AM +, Anton Ivanov wrote:
> On 21/02/2021 09:13, Salvatore Bonaccorso wrote:
> >On Sat, Feb 20, 2021 at 08:16:26PM +, Chuck Lever wrote:
> >>Confirming you are varying client-side kernels. Should the Linux
> >>NFS client maintainers be Cc'd?
> >
> >Ok,
On Thu, Jan 28, 2021 at 03:53:36PM +, Chuck Lever wrote:
> > On Jan 28, 2021, at 10:34 AM, Dan Carpenter
> > wrote:
> > Fixes tags are used for a lot of different things:
> > 1) If there is a fixes tag, then you can tell it does *NOT* have to
> >be back ported because the original
On Thu, Jan 28, 2021 at 03:05:06PM +, Chuck Lever wrote:
> Hi Colin-
>
> > On Jan 28, 2021, at 9:49 AM, Colin King wrote:
> >
> > From: Colin Ian King
> >
> > The call to find_stateid_by_type is setting the return value in *stid
> > yet the NULL check of the return is checking stid
On Thu, Jan 21, 2021 at 08:08:24PM +, David Howells wrote:
> J. Bruce Fields wrote:
> > So, I'm still confused: there must be some case where we know fscache
> > actually works reliably and doesn't corrupt your data, right?
>
> Using ext2/3, for example. I
On Thu, Jan 21, 2021 at 06:55:13PM +, David Howells wrote:
> J. Bruce Fields wrote:
>
> > > Fixing this requires a much bigger overhaul of cachefiles than this
> > > patchset
> > > performs.
> >
> > That sounds like "sometimes you may get
On Thu, Jan 21, 2021 at 05:02:57PM +, David Howells wrote:
> J. Bruce Fields wrote:
>
> > On Wed, Jan 20, 2021 at 10:21:24PM +, David Howells wrote:
> > > Note that this uses SEEK_HOLE/SEEK_DATA to locate the data available
> > > to b
On Wed, Jan 20, 2021 at 10:21:24PM +, David Howells wrote:
> Note that this uses SEEK_HOLE/SEEK_DATA to locate the data available
> to be read from the cache. Whilst this is an improvement from the
> bmap interface, it still has a problem with regard to a modern
>
How do I account for the Linux kernel development team？
On Fri, Dec 04, 2020 at 10:46:26AM -0500, Bruce Fields wrote:
> On Fri, Dec 04, 2020 at 02:59:35PM +, David Howells wrote:
> > Hi Chuck, Bruce,
> >
> > Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
> > gss_krb5_aes_encrypt() c
On Fri, Dec 04, 2020 at 04:01:53PM +, David Howells wrote:
> Bruce Fields wrote:
>
> > > Reading up on CTS, I'm guessing the reason it's like this is that CTS is
> > > the
> > > same as the non-CTS, except for the last two blocks, but the non-CTS o
On Fri, Dec 04, 2020 at 02:59:35PM +, David Howells wrote:
> Hi Chuck, Bruce,
>
> Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
> gss_krb5_aes_encrypt() code looks like the attached.
>
> >From what I can tell, in AES mode, the difference be
On Tue, Dec 1, 2020 at 12:19 PM Scott Branden
wrote:
>
> Hi Masahiro,
>
> On 2020-12-01 4:25 a.m., Masahiro Yamada wrote:
> > On Sat, Nov 28, 2020 at 9:45 AM Scott Branden
> > wrote:
> >> From: Bruce Ashfield
> >>
> >> In some cross
On Wed, Nov 25, 2020 at 03:39:33AM -0500, Huang Guobin wrote:
> Fix to return PTR_ERR() error code from the error handling case instead of
> 0 in function nfsd_file_cache_init(), as done elsewhere in this function.
>
> Fixes: 65294c1f2c5e7("nfsd: add a new struct file caching facility to nfsd")
>
Please pull
git://linux-nfs.org/~bfields/linux.git tags/nfsd-5.10-2
Just one quick fix for a tracing oops.
--b.
Scott Mayhew (1):
SUNRPC: Fix oops in the rpc_xdr_buf event class
include/trace/events/sunrpc.h | 3 ++-
1
ase of
compiling only a specific
kernel module (both in-tree and out-of-tree, e.g. 'make
M=drivers/net/ethernet/intel/ice') after
first doing a 'make modules_prepare'. Previously, that use-case would result
in a warning noting
"Symbol info of vmlinux is missing. Unresolved symbol check will be entirely
skipped" but now it
errors out after noting "No rule to make target 'vmlinux', needed by
'<...>.ko'. Stop."
Is that intentional?
Thanks,
Bruce.
On Thu, Nov 12, 2020 at 04:54:06PM +, David Howells wrote:
> Chuck Lever wrote:
>
> > Really? My understanding of the Linux kernel SUNRPC implementation is
> > that it uses asynchronous, even for small data items. Maybe I'm using
> > the terminology incorrectly.
>
> Seems to be synchronous,
On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>
> Hi Herbert, Bruce,
>
> Here's my first cut at a generic Kerberos crypto library in the kernel so
> that I can share code between rxrpc and sunrpc (and cifs?).
>
> I derived some of the parts from the sunrpc
Please pull nfsd fixes for 5.10 from
git://linux-nfs.org/~bfields/linux.git tags/nfsd-5.10-1
This is mainly server-to-server copy and fallout from Chuck's 5.10 rpc
refactoring.
--b.
Chuck Lever (3):
NFSD: NFSv3 PATHCONF Reply is improperly formed
SUNRPC: Fix general protection
On Mon, Nov 09, 2020 at 08:20:32AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> bfb5aa1685d5 ("net/sunrpc: fix useless comparison in proc_do_xprt()")
>
> is missing a Signed-off-by from its author.
I split the original patch in 2 and fixed a bug in this second patch,
but unless I
On Sat, Nov 07, 2020 at 01:49:40PM +, Alex Dewar wrote:
> On Fri, Nov 06, 2020 at 05:07:21PM -0500, J. Bruce Fields wrote:
> > Whoops, got 3 independent patches for this and overlooked this one. See
> > https://lore.kernel.org/linux-nfs/20201106205959.gb26...@fieldses.org/T/
Whoops, got 3 independent patches for this and overlooked this one. See
https://lore.kernel.org/linux-nfs/20201106205959.gb26...@fieldses.org/T/#t
--b.
On Sat, Oct 24, 2020 at 03:52:40PM +0100, Alex Dewar wrote:
> Commit c09f56b8f68d ("net/sunrpc: Fix return value for sysctl
>
On Sat, Oct 24, 2020 at 03:29:25AM +0200, Roberto Bergantinos Corpas wrote:
> Good point Geert !
>
> > How about making it a kvmalloc?
>
> I can post a new patch using kvmalloc, Bruce looks we can also
> prescind of queue_io_mutex, what do you think ?
And revert da77005f0
On Fri, Oct 23, 2020 at 11:44:38AM +0200, Geert Uytterhoeven wrote:
> Hi Bruce, Roberto,
>
> On Mon, 19 Oct 2020, J. Bruce Fields wrote:
> >On Mon, Oct 19, 2020 at 11:33:56AM +0200, Roberto Bergantinos Corpas wrote:
> >>Its possible that using AUTH_SYS and m
when doing inter server copy
Dan Aloni (1):
svcrdma: fix bounce buffers for unaligned offsets and multiple pages
Hou Tao (1):
nfsd: rename delegation related tracepoints to make them less confusing
J. Bruce Fields (8):
nfsd: remove fault injection code
nfsd: give up
On Mon, Oct 19, 2020 at 03:46:39PM +, Martijn de Gouw wrote:
> Hi
>
> On 19-10-2020 17:23, J. Bruce Fields wrote:
> > On Mon, Oct 19, 2020 at 01:42:27PM +0200, Martijn de Gouw wrote:
> >> When the passed token is longer than 4032 bytes, the remaining part
> >>
On Fri, Oct 16, 2020 at 05:18:26PM +0100, David Howells wrote:
> Hi Herbert, Dave, Trond,
>
> I've written basic gssapi-derived security support for AF_RXRPC:
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rxgk
>
> I've borrowed some bits from
On Mon, Oct 19, 2020 at 01:42:27PM +0200, Martijn de Gouw wrote:
> When the passed token is longer than 4032 bytes, the remaining part
> of the token must be copied from the rqstp->rq_arg.pages. But the
> copy must make sure it happens in a consecutive way.
Thanks. Apologies, but I don't
On Mon, Oct 12, 2020 at 05:13:08PM -0400, J. Bruce Fields wrote:
> On Fri, Oct 09, 2020 at 10:08:15PM +0200, Thomas Gleixner wrote:
> > In fact the whole thing can be simplified. You can just use time in
> > nanoseconds retrieved via ktime_get_coarse_boottime() which do
On Fri, Oct 09, 2020 at 10:08:15PM +0200, Thomas Gleixner wrote:
> On Fri, Oct 09 2020 at 09:55, J. Bruce Fields wrote:
> > Looking at how it's used in net/sunrpc/cache.c All it's doing is
> > comparing times which have all been calculated relative to the time
> > retu
On Sun, Oct 11, 2020 at 08:51:55AM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> Because every path through nfs4_find_file()'s
> switch does an explicit return, the break is not needed.
OK, applying.--b.
>
> Signed-off-by: Tom Rix
> ---
> fs/nfsd/nfs4state.c | 1 -
> 1 file changed, 1
gt; > ktime_t t = ktime_sub(tk->offs_real, tk->offs_boot);
> > + /* shift boot time stamp according to the timens offset */
> > + t = timens_ktime_to_host(CLOCK_BOOTTIME, t);
>
> Note that getbootime64() is mostly used in net/sunrpc and I don't know
> if this
On Tue, Sep 15, 2020 at 01:04:20AM -0700, syzbot wrote:
> syzbot found the following issue on:
>
> HEAD commit:581cb3a2 Merge tag 'f2fs-for-5.9-rc5' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11f5c01190
> kernel config:
On Mon, Sep 14, 2020 at 10:49:57AM -0500, Jeffrey Mitchell wrote:
> nfs_readdir_page_filler() iterates over entries in a directory, reusing
> the same security label buffer, but does not reset the buffer's length.
> This causes decode_attr_security_label() to return -ERANGE if an entry's
>
Applying, thanks.--b.
On Mon, Sep 14, 2020 at 01:07:19PM -0400, Rik van Riel wrote:
> silence nfscache allocation warnings with kvzalloc
>
> Currently nfsd_reply_cache_init attempts hash table allocation through
> kmalloc, and manually falls back to vzalloc if that fails. This makes
> the code a
This code is rarely if ever used, and there are pending patches to
remove it completely, so I don't think it's worth trying to fix a rare
memory leak at this point.
--b.
On Thu, Aug 27, 2020 at 04:02:50PM +0800, Dinghao Liu wrote:
> When kmalloc() fails, cipher should be freed
> just like when
On Fri, Aug 21, 2020 at 12:37:45AM +0100, Alex Dewar wrote:
> On Wed, Aug 12, 2020 at 08:36:31PM +, Frank van der Linden wrote:
> > On Wed, Aug 12, 2020 at 03:12:51PM +0100, Alex Dewar wrote:
> > >
> > > In nfsd4_encode_listxattrs(), the variable p is assigned to at one point
> > > but this
Applying, thanks.--b.
On Mon, Aug 17, 2020 at 06:51:26PM +0100, Alex Dewar wrote:
> Missing "is".
>
> Signed-off-by: Alex Dewar
> ---
> Ahh I see. Is this better?
> ---
> fs/nfsd/nfs4xdr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfsd/nfs4xdr.c
dd 'fallthrough' pseudo
> > keyword for switch/case use") for detail.
> >
> > Signed-off-by: Hongxiang Lou
> > Signed-off-by: Miaohe Lin
>
> LGTM. If he also approves, I assume Bruce is taking this one for v5.10.
Yep, applying, thanks.--b.
Please pull:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-5.8-2
This is just one fix for a NULL dereference if someone happens to read
/proc/fs/nfsd/client/../state at the wrong moment.
--b.
J. Bruce Fields (1):
nfsd4: fix NULL dereference in nfsd/clients display code
fs/nfsd
Nothing in since 2030 pacific
On Tue, Jul 07, 2020 at 01:29:30PM -0400, Sasha Levin wrote:
> On Tue, Jul 07, 2020 at 01:20:51PM -0400, Sasha Levin wrote:
> > On Tue, Jul 07, 2020 at 11:31:22AM -0400, J. Bruce Fields wrote:
> > > NACK.
> > >
> > > (How did this one even end u
NACK to this and following patch.--b.
On Tue, Jul 07, 2020 at 05:17:15PM +0200, Greg Kroah-Hartman wrote:
> From: J. Bruce Fields
>
> [ Upstream commit 52782c92ac85c4e393eb4a903a62e6c24afa633f ]
>
> It's handy to keep the kthread_fn just as a unique cookie to identify
> c
NACK.--b.
On Tue, Jul 07, 2020 at 05:17:13PM +0200, Greg Kroah-Hartman wrote:
> From: J. Bruce Fields
>
> [ Upstream commit 52782c92ac85c4e393eb4a903a62e6c24afa633f ]
>
> It's handy to keep the kthread_fn just as a unique cookie to identify
> classes of kthreads. E.g.
NACK.
(How did this one even end up headed for stable? It wasn't cc'd to
stable, it's not a bugfix, and it's not a small patch.)
--b.
On Tue, Jul 07, 2020 at 05:17:14PM +0200, Greg Kroah-Hartman wrote:
> From: J. Bruce Fields
>
> [ Upstream commit 28df3d1539de5090f7916f6fff03891
Acked-by: J. Bruce Fields
On Thu, Jul 02, 2020 at 12:19:43PM +0200, Ard Biesheuvel wrote:
> The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which
> was specifically issued for interoperability with Windows 2000, but was
> never intended to receive the same level o
.
Christophe Leroy (1):
SUNRPC: Add missing definition of ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
J. Bruce Fields (3):
nfsd: apply umask on fs without ACL support
nfsd4: fix nfsdfs reference count loop
nfsd: fix nfsdfs inode reference count leak
fs/nfsd/nfs4state.c | 8
On Sat, Jun 27, 2020 at 09:03:17AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 886c4fe8bdff ("nfsd4: fix nfsdfs reference count loop")
>
> Fixes tag
>
> Fixes: 2c830dd720 ("nfsd: persist nfsd filesystem across mounts")
>
> has these problem(s):
>
> - SHA1 should be at
On Fri, Jun 26, 2020 at 12:32:42PM +0200, Dmitry Vyukov wrote:
> So far this crash happened only once:
> https://syzkaller.appspot.com/bug?extid=0e37e9d19bded16b8ab9
>
> For continuous fuzzing on syzbot it usually means either (1) it's a
> super narrow race or (2) it's a previous unnoticed memory
On Fri, Jun 26, 2020 at 08:45:23PM +0800, Luo Xiaogang wrote:
> At 2020-06-24 09:29:01, "J. Bruce Fields" wrote:
> >On Mon, Jun 15, 2020 at 03:12:11PM +0800, Luo Xiaogang wrote:
> >> We load nfsd module in the docker container, kernel crash as following.
> >>
On Thu, Jun 04, 2020 at 05:58:12PM -0400, J. Bruce Fields wrote:
> On Thu, Jun 04, 2020 at 11:53:59AM +0800, Hillf Danton wrote:
> >
> > On Wed, 3 Jun 2020 12:48:49 -0400 J. Bruce Fields wrote:
> > > On Wed, Jun 03, 2020 at 10:43:26AM -0400, J. Bruce Fields wrote:
>
On Mon, Jun 15, 2020 at 08:33:40AM -0400, Chuck Lever wrote:
>
>
> > On Jun 15, 2020, at 2:25 AM, Christophe Leroy
> > wrote:
> >
> > Even if that's only a warning, not including asm/cacheflush.h
> > leads to svc_flush_bvec() being empty allthough powerpc defines
> >
ollowing two patches help?
--b.
>From 16f954bd5c481596a63271a91963bf260e2f3f46 Mon Sep 17 00:00:00 2001
From: "J. Bruce Fields"
Date: Tue, 23 Jun 2020 16:00:33 -0400
Subject: [PATCH 1/2] nfsd4: fix nfsdfs reference count loop
We don't drop the reference on the nfsdfs file
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Gustavo A. R. Silva
> Sent: Friday, June 19, 2020 10:56 AM
> To: Kirsher, Jeffrey T ; David S. Miller
> ; Jakub Kicinski
> Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject:
Thanks, applied.--b.
On Fri, May 08, 2020 at 08:40:00PM +0800, Chen Zhou wrote:
> It is more efficient to use kmemdup_nul() if the size is known exactly
> .
>
> According to doc:
> "Note: Use kmemdup_nul() instead if the size is known exactly."
>
> Signed-off-by: Chen Zhou
> ---
>
On Thu, Jun 04, 2020 at 11:53:59AM +0800, Hillf Danton wrote:
>
> On Wed, 3 Jun 2020 12:48:49 -0400 J. Bruce Fields wrote:
> > On Wed, Jun 03, 2020 at 10:43:26AM -0400, J. Bruce Fields wrote:
> > > On Wed, Jun 03, 2020 at 12:34:35PM +0800, Hillf Danton wrote:
> > >
On Wed, Jun 03, 2020 at 10:43:26AM -0400, J. Bruce Fields wrote:
> On Wed, Jun 03, 2020 at 12:34:35PM +0800, Hillf Danton wrote:
> >
> > On Tue, 2 Jun 2020 17:55:17 -0400 "J. Bruce Fields" wrote:
> > >
> > > As far as I know, this one's still unres
On Wed, Jun 03, 2020 at 12:34:35PM +0800, Hillf Danton wrote:
>
> On Tue, 2 Jun 2020 17:55:17 -0400 "J. Bruce Fields" wrote:
> >
> > As far as I know, this one's still unresolved. I can't see the bug from
> > code inspection, and we don't have a reproducer. I
On Mon, May 11, 2020 at 11:55:16PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
This is like
https://lore.kernel.org/linux-nfs/5016dd05a5e6b...@google.com/
in that we're discovering the drc is corrupt while destroying it.
I don't see the problem
As far as I know, this one's still unresolved. I can't see the bug from
code inspection, and we don't have a reproducer. If anyone else sees
this or has an idea what might be going wrong, I'd be interested.--b.
On Sun, May 17, 2020 at 11:59:12PM -0700, syzbot wrote:
> Hello,
>
> syzbot found
a potential deadlock?
It was probably a dumb thing to do in this case--I can apply the below
to make the slab global again. Kinda curious what exactly the bug is,
though.
--b.
commit 027690c75e8f
Author: J. Bruce Fields
Date: Mon Jun 1 17:44:45 2020 -0400
nfsd4: make drc_slab global, not per-net
On Fri, May 08, 2020 at 10:47:20AM +1000, Stephen Rothwell wrote:
> After merging the nfsd tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> kernel/trace/trace_hwlat.c:329:12: error: conflicting types for 'kthread_fn'
> 329 | static int kthread_fn(void *data)
>
On Fri, May 08, 2020 at 09:32:59AM +0800, Xiongfeng Wang wrote:
> When I cat parameter '/sys/module/sunrpc/parameters/pool_mode', it
> displays as follows. It is better to add a newline for easy reading.
Applying for 5.8. I assume Trond's getting the other patch.
--b.
>
> [root@hulk-202 ~]#
On Mon, May 11, 2020 at 08:07:08PM +0800, Ma Feng wrote:
> Fix warning:
>
> fs/nfsd/nfssvc.c:604:6: warning: old-style function definition
> [-Wold-style-definition]
> bool i_am_nfsd()
Applying for 5.8, thanks.--b.
> ^
>
> Reported-by: Hulk Robot
> Signed-off-by: Ma Feng
>
Thanks, applying for 5.8.--b.
On Tue, May 05, 2020 at 04:45:37PM +0800, YueHaibing wrote:
> commit 49b28684fdba ("nfsd: Remove deprecated nfsctl system call and related
> code.")
> left behind this, remove it.
>
> Signed-off-by: YueHaibing
> ---
> net/sunrpc/svcauth_unix.c | 9 -
> 1
On Wed, May 06, 2020 at 11:39:20AM -0400, Tejun Heo wrote:
> Hello, Bruce.
>
> On Wed, May 06, 2020 at 11:36:58AM -0400, J. Bruce Fields wrote:
> > On Tue, May 05, 2020 at 05:25:27PM -0400, J. Bruce Fields wrote:
> > > On Tue, May 05, 2020 at 05:09:56PM -0400, Tejun
On Tue, May 05, 2020 at 05:25:27PM -0400, J. Bruce Fields wrote:
> On Tue, May 05, 2020 at 05:09:56PM -0400, Tejun Heo wrote:
> > It's not the end of the world but a bit hacky. I wonder whether something
> > like the following would work better for identifying worker type so that
On Tue, May 05, 2020 at 05:09:56PM -0400, Tejun Heo wrote:
> Hello,
>
> On Tue, May 05, 2020 at 05:01:18PM -0400, J. Bruce Fields wrote:
> > On Mon, May 04, 2020 at 10:15:14PM -0400, J. Bruce Fields wrote:
> > > Though now I'm feeling greedy: it would be nic
On Mon, May 04, 2020 at 10:15:14PM -0400, J. Bruce Fields wrote:
> Though now I'm feeling greedy: it would be nice to have both some kind
> of global flag, *and* keep kthread->data pointing to svc_rqst (as that
> would give me a simpler and quicker way to figure out which client is
&
On Tue, May 05, 2020 at 11:54:05AM -0400, Tejun Heo wrote:
> Hello, Bruce.
>
> On Mon, May 04, 2020 at 10:15:14PM -0400, J. Bruce Fields wrote:
> > We're currently using it to pass the struct svc_rqst that a new nfsd
> > thread needs. But once the new thread has gotten t
On Fri, May 01, 2020 at 02:21:54PM -0400, Tejun Heo wrote:
> Hello,
>
> On Fri, May 01, 2020 at 10:59:24AM -0700, Linus Torvalds wrote:
> > Which kind of makes me want to point a finger at Tejun. But it's been
> > mostly PeterZ touching this file lately..
>
> Looks fine to me too. I don't quite
On Fri, May 01, 2020 at 07:05:46PM +, Trond Myklebust wrote:
> On Fri, 2020-05-01 at 14:49 -0400, J. Bruce Fields wrote:
> > On Fri, May 01, 2020 at 02:21:54PM -0400, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Fri, May 01, 2020 at 10:59:24AM -0700, Linu
> > same group. Can't that be done with kthread_data()?
>
> I _think_ Bruce wants the signal handling unification too, because
> nfsd wants to react to being shut down with signals.
No, maybe kthread_data() might do the job.
(I don't see how this would help with signal handlin
On Fri, May 01, 2020 at 02:21:54PM -0400, Tejun Heo wrote:
> Hello,
>
> On Fri, May 01, 2020 at 10:59:24AM -0700, Linus Torvalds wrote:
> > Which kind of makes me want to point a finger at Tejun. But it's been
> > mostly PeterZ touching this file lately..
>
> Looks fine to me too. I don't quite
From: "J. Bruce Fields"
Allow subsystems to run their own kthreadd's.
I'm experimenting with this to allow nfsd to put its threads into its
own thread group to make it easy for the vfs to tell when nfsd is
breaking one of its own leases.
Signed-off-by: J. Bruce Fields
---
inc
From: "J. Bruce Fields"
This is so knfsd can add CLONE_THREAD.
Signed-off-by: J. Bruce Fields
---
include/linux/kthread.h | 3 ++-
kernel/kthread.c| 11 +++
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/linux/kthread.h b/include/linux/kthre
From: "J. Bruce Fields"
This will also simplify a following patch that allows multiple
kthreadd's.
Signed-off-by: J. Bruce Fields
---
init/init_task.c | 3 +++
kernel/fork.c| 4
kernel/kthread.c | 3 +--
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/init/i
From: "J. Bruce Fields"
These patches allow a caller to create its own kthreadd.
The motivation is file delegations: currently any write operation from a
client breaks all delegations, even delegations held by the same client.
To fix that, we need to know which client is performi
From: "J. Bruce Fields"
Trivial refactoring, no change in behavior.
Not really necessary, a separate function for the inner loop just seems
a little nicer to me.
Signed-off-by: J. Bruce Fields
---
kernel/kthread.c | 33 +++--
1 file changed, 19 inserti
On Sat, Oct 19, 2019 at 06:37:22PM +0530, Bhaskar Chowdhury wrote:
> This patch will remove old kernel from the system in a selective way.
Please don't comment out code, just delete it, git's there to keep the
old code.
There's some redundant code that should be inside a loop.
A little more
On Sat, Oct 12, 2019 at 08:20:04PM +0200, Markus Elfring wrote:
> I tried another script for the semantic patch language out.
> This source code analysis approach points out that the implementation
> of the function “xdr_netobj_dup” contains still an unchecked call
> of the function “kmemdup”.
>
On Wed, Oct 09, 2019 at 09:51:23AM +1100, NeilBrown wrote:
> On Tue, Oct 08 2019, J . Bruce Fields wrote:
>
> > On Tue, Oct 08, 2019 at 10:02:53AM +, Pavel Tikhomirov wrote:
> >> Add Neil to CC, sorry, had lost it somehow...
> >
> > Always happy when
On Tue, Oct 08, 2019 at 10:02:53AM +, Pavel Tikhomirov wrote:
> Add Neil to CC, sorry, had lost it somehow...
Always happy when we can fix a bug by deleting code, and your
explanation makes sense to me, but I'll give Neil a chance to look it
over if he wants.
--b.
>
> On 10/1/19 11:03 AM,
On Tue, Oct 8, 2019 at 8:36 AM Oleg Nesterov wrote:
>
> On 10/08, Bruce Ashfield wrote:
> >
> > So I've been looking through the config delta's and late last night, I was
> > able to move the runtime back to a failed 4 minute state by adding the
> > CONFIG_PREEMPT se
On Mon, Oct 7, 2019 at 7:28 PM Roman Gushchin wrote:
>
> On Mon, Oct 07, 2019 at 04:11:07PM -0400, Bruce Ashfield wrote:
> > On Mon, Oct 7, 2019 at 8:54 AM Bruce Ashfield
> > wrote:
> > >
> > > On Thu, Oct 3, 2019 at 8:09 PM Roman Gushchin wrote:
> >
On Mon, Oct 7, 2019 at 8:54 AM Bruce Ashfield wrote:
>
> On Thu, Oct 3, 2019 at 8:09 PM Roman Gushchin wrote:
> >
> > On Wed, Oct 02, 2019 at 05:59:36PM -0400, Bruce Ashfield wrote:
> > > On Wed, Oct 2, 2019 at 2:19 PM Roman Gushchin wrote:
> > > >
>
On Thu, Oct 3, 2019 at 8:09 PM Roman Gushchin wrote:
>
> On Wed, Oct 02, 2019 at 05:59:36PM -0400, Bruce Ashfield wrote:
> > On Wed, Oct 2, 2019 at 2:19 PM Roman Gushchin wrote:
> > >
> > > On Wed, Oct 02, 2019 at 12:18:54AM -0400, Bruce Ashfield wrote:
> >
On Wed, Oct 02, 2019 at 04:35:55PM -0400, Jeff Layton wrote:
> On Wed, 2019-10-02 at 15:27 -0400, J. Bruce Fields wrote:
> > On Wed, Oct 02, 2019 at 08:28:40AM -0400, Jeff Layton wrote:
> > > For the byte ranges, the catch there is that extending the userland
> > &g
1 - 100 of 3178 matches
Mail list logo
