> On 3. Mar 2022, at 05:58, David Laight wrote:
>
> From: Xiaomeng Tong
>> Sent: 03 March 2022 02:27
>>
>> On Wed, 2 Mar 2022 14:04:06 +, David Laight
>> wrote:
>>> I think that it would be better to make any alternate loop macro
>>> just set the variable to NULL on the loop exit.
>>> Tha
On Thu, 3 Mar 2022 04:58:23 +, David Laight wrote:
> on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > The problem is the mis-use of iterator outside the loop on exit, and
> > the iterator will be the HEAD's container_of pointer which pointers
> > to a type-confused struct. Sidenote: The *
From: Xiaomeng Tong
> Sent: 03 March 2022 02:27
>
> On Wed, 2 Mar 2022 14:04:06 +, David Laight
> wrote:
> > I think that it would be better to make any alternate loop macro
> > just set the variable to NULL on the loop exit.
> > That is easier to code for and the compiler might be persuaded
On 2022/3/3 3:45, Jaegeuk Kim wrote:
On 03/02, Chao Yu wrote:
On 2022/3/2 13:26, Jaegeuk Kim wrote:
On 03/02, Chao Yu wrote:
ping,
On 2022/2/25 11:02, Chao Yu wrote:
On 2022/2/3 22:57, Chao Yu wrote:
On 2022/2/3 9:51, Jaegeuk Kim wrote:
On 01/29, Chao Yu wrote:
On 2022/1/29 8:37, Jaegeuk
On Wed, 2 Mar 2022 14:04:06 +, David Laight
wrote:
> I think that it would be better to make any alternate loop macro
> just set the variable to NULL on the loop exit.
> That is easier to code for and the compiler might be persuaded to
> not redo the test.
No, that would lead to a NULL derefe
On Tue, Mar 1, 2022 at 8:10 PM Nick Terrell wrote:
>
>
>
> > On Feb 20, 2022, at 1:45 AM, Sedat Dilek wrote:
> >
> > On Tue, Nov 9, 2021 at 2:24 AM Nick Terrell wrote:
> >>
> >> From: Nick Terrell
> >>
> >> Hi Linus,
> >>
> >> I am sending you a pull request to add myself as the maintainer of z
On Wed, Mar 02, 2022 at 12:18:45PM -0800, Linus Torvalds wrote:
> On Wed, Mar 2, 2022 at 12:07 PM Kees Cook wrote:
> >
> > I've long wanted to change kfree() to explicitly set pointers to NULL on
> > free. https://github.com/KSPP/linux/issues/87
>
> We've had this discussion with the gcc people i
On Wed, Mar 2, 2022 at 12:07 PM Kees Cook wrote:
>
> I've long wanted to change kfree() to explicitly set pointers to NULL on
> free. https://github.com/KSPP/linux/issues/87
We've had this discussion with the gcc people in the past, and gcc
actually has some support for it, but it's sadly tied to
On Wed, Mar 02, 2022 at 10:29:31AM +0100, Rasmus Villemoes wrote:
> This won't help the current issue (because it doesn't exist and might
> never), but just in case some compiler people are listening, I'd like to
> have some sort of way to tell the compiler "treat this variable as
> uninitialized f
On 03/02, Chao Yu wrote:
> On 2022/3/2 13:45, Jaegeuk Kim wrote:
> > On 03/01, Jaegeuk Kim wrote:
> > > On 03/01, Jaegeuk Kim wrote:
> > > > On 03/02, Chao Yu wrote:
> > > > > On 2022/3/1 12:48, Jaegeuk Kim wrote:
> > > > > > 1. waiting for f2fs_evict_inode
> > > > > > [ 5560.043945] __wait_on_fre
On 03/02, Chao Yu wrote:
> On 2022/3/2 13:26, Jaegeuk Kim wrote:
> > On 03/02, Chao Yu wrote:
> > > ping,
> > >
> > > On 2022/2/25 11:02, Chao Yu wrote:
> > > > On 2022/2/3 22:57, Chao Yu wrote:
> > > > > On 2022/2/3 9:51, Jaegeuk Kim wrote:
> > > > > > On 01/29, Chao Yu wrote:
> > > > > > > On 20
On 28/02/2022 11:08, Jakob Koschel wrote:
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.
While it is safe to use the pointer to determine if it was computed
based o
From: Xiaomeng Tong
> Sent: 02 March 2022 09:31
>
> On Mon, 28 Feb 2022 16:41:04 -0800, Linus Torvalds
> wrote:
> >
> > But basically to _me_, the important part is that the end result is
> > maintainable longer-term.
>
> I couldn't agree more. And because of that, I stick with the following
> a
On 02/03/2022 00.55, Linus Torvalds wrote:
> On Tue, Mar 1, 2022 at 3:19 PM David Laight wrote:
>>
> With the "don't use iterator outside the loop" approach, the exact
> same code works in both the old world order and the new world order,
> and you don't have the semantic confusion. And *if* you
On Mon, 28 Feb 2022 16:41:04 -0800, Linus Torvalds
wrote:
>
> But basically to _me_, the important part is that the end result is
> maintainable longer-term.
I couldn't agree more. And because of that, I stick with the following
approach because it's maintainable longer-term than "type(pos) pos"
On 2022/3/2 13:26, Jaegeuk Kim wrote:
On 03/02, Chao Yu wrote:
ping,
On 2022/2/25 11:02, Chao Yu wrote:
On 2022/2/3 22:57, Chao Yu wrote:
On 2022/2/3 9:51, Jaegeuk Kim wrote:
On 01/29, Chao Yu wrote:
On 2022/1/29 8:37, Jaegeuk Kim wrote:
On 01/28, Chao Yu wrote:
On 2022/1/28 5:59, Jaegeuk
16 matches
Mail list logo