On Wed, Jan 15, 2025 at 03:52:23PM -0800, Kees Cook wrote:
> > You seem to be saying you're pushing an internal feature on upstream and
> > only care about internal use cases, this is not how upstream works, as
> > Matthew alludes to.
>
> Internal? No. Chrome OS and Android. Linux runs more Androi
On Mon, Dec 16, 2024 at 05:26:19PM -0800, Kees Cook wrote:
> -extern bool inet_addr_is_any(struct sockaddr *addr);
> +extern bool inet_addr_is_any(struct sockaddr_storage *addr);
You might want to drop the pointless extern here.
Otherwise this looks great:
Reviewed-by: Christoph Hellwig
On Wed, Nov 20, 2024 at 04:46:40PM -0700, Brian Johannesmeyer wrote:
> Thank you for the suggestion. I hacked together a bitmap-based
> approach as you proposed, and while it does improve memory efficiency
> by reducing the per-block metadata overhead, it unfortunately appears
> to significantly im
On Tue, Nov 19, 2024 at 09:55:28PM +0100, Brian Johannesmeyer wrote:
> + page->blocks_per_page = pool->allocation / pool->size;
> + page->blocks = kmalloc_array(page->blocks_per_page,
> + sizeof(struct dma_block), GFP_KERNEL);
Given that you now need an ar
On Tue, Nov 19, 2024 at 09:55:27PM +0100, Brian Johannesmeyer wrote:
> We discovered a security-related issue in the DMA pool allocator.
>
> V1 of our RFC was submitted to the Linux kernel security team. They
> recommended submitting it to the relevant subsystem maintainers and the
> hardening mai
On Tue, Nov 05, 2024 at 10:53:39AM -0800, Andrew Morton wrote:
> > Might be worth adding that nothing does a sizeof of the type or
> > variables of the type, so just hcanging it is fine.
> >
> > Otherwise looks good:
> >
> > Reviewed-by: Christoph Hellwig
&
nothing does a sizeof of the type or
variables of the type, so just hcanging it is fine.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
Andrew, can you pick this up through -mm as there is no freevxfs tree?
On Fri, Apr 05, 2024 at 07:45:08PM +, Justin Stitt wrote:
> - memcpy(offset, prefix, prefix_len);
> - offset += prefix_len;
> - strncpy(offset, (char *)name, namelen); /* real name */
> - offset += namelen;
> - *offset = '\0';
> +
> + combined_len = prefi
On Mon, Apr 01, 2024 at 11:01:38PM +, Justin Stitt wrote:
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -1755,10 +1755,8 @@ xfs_ioc_getlabel(
> /* Paranoia */
> BUILD_BUG_ON(sizeof(sbp->sb_fname) > FSLABEL_MAX);
>
> - /* 1 larger than sb_fname, so this ensures a trailing NUL char */
> -
On Fri, Dec 08, 2023 at 10:11:10AM -0800, Song Liu wrote:
> We marked it as deprecated about 2.5 years ago. But to be honest,
> I currently don't have a plan to remove it. I guess I should start thinking
> about it.
Let's just kill it off ASAP. It never had a large user base and based
by dm-multi
On Tue, Dec 05, 2023 at 01:39:47PM -0800, Nick Desaulniers wrote:
> Hmm...how does one know that linux/bits.h is the higher-level include
> of asm/bitsperlong.h?
I think this the wrong way of thinking. In general we should always
avoid including asm/ headers unless there is no other way. No othe
On Thu, Oct 26, 2023 at 12:40:37PM -0700, Kees Cook wrote:
> Solve two ergonomic issues with struct seq_buf;
>
> 1) Too much boilerplate is required to initialize:
>
> struct seq_buf s;
> char buf[32];
>
> seq_buf_init(s, buf, sizeof(buf));
>
> Instead, we can build this direc
On Fri, Oct 20, 2023 at 11:30:49AM -0700, Kees Cook wrote:
> I'm curious where you looked and didn't find documentation -- perhaps
> there is an improvement to be made to aim one to where the existing
> documentation lives?
My order was the following:
- look for kernel doc on the main function i
Looks good:
Reviewed-by: Christoph Hellwig
On Wed, Oct 18, 2023 at 11:01:54PM -0700, Kees Cook wrote:
> Almost all of the remaining strncpy() usage is just string to string
> copying, but the corner cases that are being spun out that aren't
> strscpy() or strscpy_pad() are covered by strtomem(), kmemdup_nul(),
> and memcpy(). Each of these
On Wed, Oct 18, 2023 at 10:48:49PM +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
If we want that we need to stop pretendening direct manipulation of
nul-termi
On Tue, Oct 03, 2023 at 04:25:11PM -0700, Kees Cook wrote:
> struct workqueue_struct *work_q;
> struct kref ref;
> struct rcu_head rcu;
> - struct nvmet_fc_fcp_iod fod[]; /* array of fcp_iods */
> + struct nvmet_
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 via the call of kill_super
On Thu, Sep 14, 2023 at 06:38:43AM +0100, Al Viro wrote:
> It's worse - look at the rationale for 2c18a63b760a "super: wait until
> we passed kill super". Basically, "don't remove from the lists
> until after block device closing". IOW, we have
As of this stage we don't even touch anything relat
On Thu, Sep 14, 2023 at 12:27:12AM +0100, Al Viro wrote:
> On Wed, Sep 13, 2023 at 08:09:57AM -0300, Christoph Hellwig wrote:
> > Releasing an anon dev_t is a very common thing when freeing a
> > super_block, as that's done for basically any not block based file
> >
On Thu, Sep 14, 2023 at 09:56:57AM +0200, Christian Brauner wrote:
> > BTW, this part of commit message in 2c18a63b760a is rather confused:
> > Recent rework moved block device closing out of sb->put_super() and into
> > sb->kill_sb() to avoid deadlocks as s_umount is held in put_super() an
On Wed, Sep 13, 2023 at 06:35:03PM +0200, Christian Brauner wrote:
> I wouldn't mind s/s/sb/ here as well. So we stop using @s in some and
> @sb in other places.
I did that in an earlier version and decided to have some less churn.
But I can add it back.
On Wed, Sep 13, 2023 at 12:10:56PM -0400, Alan Stern wrote:
> On Wed, Sep 13, 2023 at 08:10:04AM -0300, Christoph Hellwig wrote:
> > Creating new a new super_block vs freeing the old one for single instance
> > file systems is serialized by the wait for SB_DEAD.
> >
>
23 matches
Mail list logo
