On Sat, Feb 22, 2025 at 01:12:47PM +0100, Mateusz Guzik wrote:
> General tune is not holding the codebase hostage to obsolete (and
> probably not at all operational) components. If in doubt, prune it.
What exactly is being held hostage, though? Do we have an API change
that gets blocked just by
On Tue, Feb 04, 2025 at 02:13:37PM +1030, Gustavo A. R. Silva wrote:
> +#define anode_btree container_of(&anode->btree, struct bplus_header, __hdr)
> +#define ranode_btree container_of(&ranode->btree, struct bplus_header, __hdr)
> +#define fnode_btree container_of(&fnode->btree, struct bplus_hea
On Fri, May 17, 2024 at 02:13:22AM +0100, Matthew Wilcox wrote:
> On Fri, May 17, 2024 at 12:29:06AM +, Justin Stitt wrote:
> > When running syzkaller with the newly reintroduced signed integer
> > overflow sanitizer we encounter this report:
>
> why do you keep saying it's unintentional? it'
On Fri, May 10, 2024 at 07:33:12AM +0100, Al Viro wrote:
> As the matter of fact, it would be interesting to find out
> which instances, if any, do *not* have that relationship
> between SEEK_CUR and SEEK_SET. If such are rare, it might
> make sense to mark them as such in file_op
On Fri, May 10, 2024 at 05:48:05AM +0100, Al Viro wrote:
> On Fri, May 10, 2024 at 03:26:08AM +, Justin Stitt wrote:
>
> > This feels like a case of accidental correctness. You demonstrated that
> > even with overflow we end up going down a control path that returns an
>
On Fri, May 10, 2024 at 03:26:08AM +, Justin Stitt wrote:
> This feels like a case of accidental correctness. You demonstrated that
> even with overflow we end up going down a control path that returns an
> error code so all is good.
No. It's about a very simple arithmetical fact: the smalle
On Fri, May 10, 2024 at 01:49:06AM +0100, Al Viro wrote:
> On Fri, May 10, 2024 at 12:35:51AM +, Justin Stitt wrote:
> > @@ -147,7 +147,9 @@ loff_t dcache_dir_lseek(struct file *file, loff_t
> > offset, int whence)
> > struct dentry *dentry = file->f_path.dentry
On Fri, May 10, 2024 at 12:35:51AM +, Justin Stitt wrote:
> @@ -147,7 +147,9 @@ loff_t dcache_dir_lseek(struct file *file, loff_t offset,
> int whence)
> struct dentry *dentry = file->f_path.dentry;
> switch (whence) {
> case 1:
> - offset += file-
On Thu, May 09, 2024 at 12:15:40PM -0700, Linus Torvalds wrote:
> On Thu, 9 May 2024 at 11:48, Al Viro wrote:
> >
> > FWIW, the thing that somewhat worries me about having a helper along
> > the lines of combine_to_u64(low, high) is that
> > foo->sp
On Thu, May 09, 2024 at 11:39:04AM -0700, Linus Torvalds wrote:
> .. it might also actually be a good idea *IF* we were to have some
> kind of "implicit cast drops bits" warning, in that the compiler for
> that case wouldn't remove the upper bits calculation, but would
> trigger a warning if they
On Thu, May 09, 2024 at 08:38:28AM -0700, Linus Torvalds wrote:
> Going the other way is similar:
>
> all_bits = low_bits + ((u64) high_bits << 16) << 16);
>
> and again, the compiler will recognize this idiom and do the right
> thing (and if 'all_bits' is only 32-bit, the compiler will
On Tue, May 07, 2024 at 11:17:57PM +, Justin Stitt wrote:
> I wonder, though, why isn't loff_t an unsigned type?
Consider
lseek(fd, -10, SEEK_CUR)
PS: the above is *not* an endorsement of the proposed patch or
KASAN overflow nonsense in general.
On Thu, Dec 14, 2023 at 09:04:00PM +, Al Viro wrote:
> drivers/firmware/arm_scmi/shmem.c:13:#include
Should just use linux/bug.h and be done with that.
> drivers/platform/x86/hp/hp-bioscfg/passwdobj-attributes.c:10:#include
>
Completely pointless; not to mention that none of
On Wed, Dec 06, 2023 at 12:09:17PM +0900, Greg KH wrote:
> > slap #include "unaligned.h" into their traps.c and unaligned.c
> > (callers and definitions resp.) and strip those from asm/unaligned.h?
> > At that point we can remove arch/{arc,parisc}/asm/unaligned.h - everything
> > will pick include/
On Wed, Dec 06, 2023 at 12:55:42AM +, Al Viro wrote:
> On Wed, Dec 06, 2023 at 08:46:50AM +0900, Greg KH wrote:
> > > >
> > > > But of course, it doesn't always hold true, there are a few minor
> > > > exceptions, but they are rare.
>
On Wed, Dec 06, 2023 at 08:46:50AM +0900, Greg KH wrote:
> > >
> > > But of course, it doesn't always hold true, there are a few minor
> > > exceptions, but they are rare.
> >
> > $ grep -r \\#include lib | grep asm
> >
> > shows quite a few exceptions, and just in lib/.
> >
> > For example, lib
On Tue, Dec 05, 2023 at 10:15:21PM +, Al Viro wrote:
> It would certainly be nice to have such information in the tree;
> "where should I pick $SYMBOL from?" is something one needs to
> find out often enough. To a large extent it's covered by "where
> in i
On Wed, Dec 06, 2023 at 12:01:56AM +0200, Andy Shevchenko wrote:
> On Tue, Dec 05, 2023 at 01:51:10PM -0800, Nick Desaulniers wrote:
> > On Tue, Dec 5, 2023 at 1:38 PM Al Viro wrote:
> > > On Tue, Dec 05, 2023 at 08:58:53PM +, tanz...@google.com wrote:
>
> ...
>
On Tue, Dec 05, 2023 at 09:38:07PM +, Al Viro wrote:
> It also breeds includes of asm/*.h, by the look of the output, which is
> not a good thing in general ;-/ E.g. #include *anywhere*
> outside of linux/uaccess.h is a bad idea.
Let me elaborate a bit:
Consider e.g. a situatio
On Tue, Dec 05, 2023 at 01:39:47PM -0800, Nick Desaulniers wrote:
> The tooling Tanzir is working on does wrap IWYU, and does support such
> mapping (of 'low level' to 'high level' headers; more so, if it
> recommends X you can override to suggest Y instead).
>
> arch/nios/ also doesn't provide a
On Tue, Dec 05, 2023 at 08:58:53PM +, tanz...@google.com wrote:
> This diff uses an open source tool include-what-you-use (IWYU) to modify
> the include list changing indirect includes to direct includes.
How does it account for arch- and config-dependent indirect includes?
In particular, on
On Sat, Dec 02, 2023 at 01:22:15PM -0800, Kees Cook wrote:
> static void *pstore_ftrace_seq_start(struct seq_file *s, loff_t *pos)
> {
> @@ -338,9 +339,8 @@ int pstore_mkfile(struct dentry *root, struct
> pstore_record *record)
> {
> struct dentry *dentry;
> struct inode
On Sat, Dec 02, 2023 at 09:42:12PM +, Al Viro wrote:
> I'll poke around and see what I can suggest; said that, one thing I have
> spotted there on the quick look is that you are exposing hashed dentry
> associated
> with your inode before you set its ->i_private.
... an
On Sat, Dec 02, 2023 at 01:34:32PM -0800, Kees Cook wrote:
> On Sat, Dec 02, 2023 at 09:28:46PM +0000, Al Viro wrote:
> > On Sat, Dec 02, 2023 at 01:22:13PM -0800, Kees Cook wrote:
> > > Allow __free(iput) markings for easier cleanup on inode allocations.
> >
> > NA
On Sat, Dec 02, 2023 at 01:22:13PM -0800, Kees Cook wrote:
> Allow __free(iput) markings for easier cleanup on inode allocations.
NAK. That's a bloody awful idea for that particular data type, since
1) ERR_PTR(...) is not uncommon and passing it to iput() is a bug.
2) the common p
On Tue, Oct 10, 2023 at 10:44:09AM +0200, Christian Brauner wrote:
> > list removal should happen after generic_shutdown_super(). Sure, you
> > want the superblock to serve as bdev holder, which leads to fun
> > with -EBUSY if mount comes while umount still hadn't closed the
> > device. I suspect
On Mon, Oct 02, 2023 at 08:46:46AM +0200, Christoph Hellwig wrote:
> On Tue, Sep 26, 2023 at 10:25:15PM +0100, Al Viro wrote:
> > Before your patch: foo_kill_super() calls kill_anon_super(),
> > which calls kill_super_notify(), which removes the sucker from
> > the list, t
On Tue, Sep 26, 2023 at 10:25:15PM +0100, Al Viro wrote:
> Before your patch: foo_kill_super() calls kill_anon_super(),
> which calls kill_super_notify(), which removes the sucker from
> the list, then frees ->s_fs_info. After your patch:
> removal from the lists happens
On Tue, Sep 26, 2023 at 11:38:34AM +0200, Christoph Hellwig wrote:
> How?
>
> Old sequence before his patch:
>
> deactivate_locked_super()
> -> kill_anon_super()
> -> generic_shutdown_super()
> -> kill_super_notify()
> -> free_anon_bdev()
> ->
29 matches
Mail list logo
